A language model answers a message. An agent pursues a goal.
That is the fundamental distinction, and it runs deeper than it looks. When you use an LLM the classic way (one question, one answer), the model is passive. It receives text, it produces text. The action belongs to the human. In an agentic system, that separation disappears: the AI can observe, decide, act, then observe again. It operates on the world, not just on text.
This paradigm shift has precise architectural consequences. Here is how it works.
The fundamental loop: act-observe
An agent is not a linear program that executes steps in a fixed order. It is a system that runs in a loop. On each iteration:
- It receives a context: the current state of the problem, the memory of previous exchanges, the results of past actions.
- It reasons: it produces a plan or identifies the next relevant action.
- It acts: it calls a tool, modifies a file, sends a request, writes a message.
- It observes: it retrieves the result of the action and integrates it into its context.
- It starts over, until the goal is reached or a stopping point is hit.
Structurally, this loop resembles that of a classic program built around an event loop, except that the decision engine is an LLM, capable of adapting to unanticipated situations and interpreting instructions in natural language.
Memory: what separates an agent from a script
A script reads parameters and produces a result. An agent accumulates state over time.
Memory in an agentic system takes several forms:
Short-term memory: the LLM's context window. Everything in it is directly accessible to the model: the exchange history, the results of tool calls, the system instructions. It is volatile: it disappears when the session ends.
Long-term memory: persistent files on disk. An agent can write to memory files between two runs, reread what it learned in previous executions, and adapt its behavior accordingly. This is what allows an agent to improve over time: it accumulates lessons, conventions, and mistakes not to repeat.
Semantic memory: a vector database, for more elaborate systems. Rather than reading the entire memory on every run, the agent performs a similarity search to retrieve the information most relevant to the current context. Useful when the memory grows too large to fit in the context.
The distinction between short-term and long-term memory is critical to understanding why an agent can be consistent within a session yet inconsistent from one session to the next if persistent memory is not managed.
Tools: how the agent acts on the world
An LLM on its own can only produce text. Tools are what give it the ability to act.
Technically, a tool is a function the agent can call, whose signature the LLM knows (name, parameters, description), and whose result is fed back into the context. From the model's point of view, calling a tool feels like writing a line of code: it knows what the function does, it chooses to call it with the right parameters, and it receives the return value.
Common tools in an agentic system:
- File read/write: the agent can read source code, modify files, create new documents.
- Command execution: run scripts, tests, builds, migrations.
- API calls: query external services, create issues, post messages.
- Search: grep through the codebase, web search, database queries.
- Sub-agents: call other specialized agents, delegate sub-tasks.
The list of available tools defines the agent's scope of action. A code review agent that only has file-read access cannot merge a PR. This constraint is a feature, not a limitation: it makes it possible to calibrate precisely what an agent is allowed to do.
Orchestration: several agents, one mission
A single agent can cover one domain. Several orchestrated agents can cover an entire process.
Orchestration is the coordination of several specialized agents toward a common goal. Each agent has a defined role, a limited set of tools, precise instructions. The orchestrator (which can itself be an LLM) breaks the overall mission down into sub-tasks and assigns them to the right agents.
This architecture has interesting properties:
Specialization: a content agent does not need to know how to deploy to production. Specialization reduces the risk of hallucination in unfamiliar territory and produces more reliable outputs within the covered domain.
Parallelism: independent agents can work simultaneously on non-conflicting tasks. What would take several hours sequentially can be compressed into minutes.
Auditability: each agent leaves a trace of its actions. In a system like KittyClaw, every ticket movement, every comment, every commit is attributed to the agent that produced it. You can replay the history and understand why the system made a given decision.
Robustness: an agent that fails does not impact the others. The system can handle the error locally (retry, escalate to a human, move on to the next task) without the whole thing collapsing.
The harness: the execution infrastructure
The orchestrator and the harness play distinct roles that are worth keeping separate.
The orchestrator decides what to do and when: it breaks down the overall goal, selects the appropriate agent for each sub-task, assigns the work and manages dependencies. It operates at the business-logic level.
The harness is the infrastructure that concretely executes each agent. It takes care of:
- Context injection: loading the skill files, the persistent memory and the system instructions before launching the agent. The agent does not receive a bare prompt, it receives a prepared environment.
- Permission management: defining which tools are available in this specific run: read-only, writes limited to one directory, API access allowed or not.
- Lifecycle: launching the agent in response to a trigger, monitoring its execution, capturing its output, handling timeouts and errors.
- Traceability: recording each of the agent's actions in a structured way, for audit and debugging.
In KittyClaw, this separation is explicit: the dispatch engine is the orchestrator (it reads the tickets, applies the assignment rules, triggers the runs), and the harness is what wraps each invocation of the claude CLI, injecting the preamble, the skill and the memory, and reporting the result back on the corresponding ticket.
This distinction has a practical consequence: you can switch LLM models without touching the orchestration logic, and you can modify the assignment rules without touching each agent's execution environment.
Token cost: don't delegate to the LLM what a script can do
Agentic systems have an operational cost that does not exist in classic LLM usage: each step of the act-observe loop passes the entire current context through the model. As the session progresses (exchange history, results of tool calls, injected memory), the context grows, and the token cost grows with it.
An agent that executes 20 steps on a context of 50,000 tokens can represent several million billed tokens for a single task. On a project with dozens of agents running in parallel, the bill can become significant very quickly.
The golden rule is simple: don't ask the LLM to do what a deterministic script can do.
If the result of an action is predictable from fixed rules (changing a ticket's status when a commit is pushed, posting an automatic comment when CI turns green, archiving a file according to a naming convention), then it is the job of an automation, not an agent.
KittyClaw applies this principle at the level of its automation engine. Simple triggers (ticketInColumn, statusChange, ticketCommentAdded) are handled directly by rules without invoking an LLM. The model is only called for tasks that actually require judgment: reading the content of a ticket and deciding what to do, analyzing code and producing a review, writing an article from a brief.
{
"trigger": { "type": "ticketInColumn", "columns": ["Todo"] },
"conditions": [{ "type": "assignedTo", "slugs": ["content-writer"] }],
"actions": [
{ "type": "moveTicketStatus", "to": "InProgress" },
{ "type": "runAgent", "agent": "content-writer" }
]
}
In this example, the column movement and the agent launch are orchestrated by the harness without touching an LLM. The agent itself is invoked exactly once, with a clean context, to do the work that justifies its existence.
This principle of token sobriety is not just a matter of cost. It is also a matter of reliability: less useless context in the window means less risk of the agent getting lost in irrelevant information. A well-scoped agent, with a targeted context and automations handling the mechanical steps, produces more consistent results than a generalist agent that has been handed everything.
What doesn't change: human judgment
Agentic AI is powerful because it can act without constant supervision. It is risky for exactly the same reason.
A well-configured agent stays in its lane. But edge cases exist: an ambiguity in the spec, an unexpected system state, a decision with irreversible consequences. Without a mechanism for delegating to a human, the agent keeps going, either by improvising or by silently getting stuck.
Mature agentic systems build in explicit human checkpoints. This is not an admission of the system's weakness: it is intentional design. The ideal design is not a fully autonomous agent, but an agent that is autonomous within its scope and transparent about its limits.
That is where human orchestration keeps all its value: not to do what agents do well, but to make the decisions that agents should not make alone.
This text is the reference deep-dive article on agentic AI for the Ekioo blog. The operational lessons learned (parallelism traps, memory, visibility) are in Agentic System Hygiene. The multi-project practice is in Cadence Over Volume.