Headless agents and the ones who still call them
In a long conversation with people who ship real agent systems, the question that finally landed after forty minutes was simple. Can you explain what you mean by a headless agent? Preferably with an example.
It was one of those rooms where everyone in it has already built at least one agent platform or a close cousin of one. Three different dialects had already taken turns. A consultant spoke about ambient agents with the calm of a man who had never experienced the real Russian Tuesday – the kind of day when from the very morning absolutely everything falls apart and it continues all day. A practitioner who seemed to need his model even to turn the lights on in the garage live-demonstrated in the chat how a model would reply if the context were only richer. Someone from the more vibe end of the table offered the overnight-sketch version and promised the ownership would come later.
The language was precise in each of them. The diagrams multiplied. We had already covered state machines, memory layers, tool contracts, human-in-the-loop patterns, and the difference between a skill and a prompt that hopes it is a skill.
Forty minutes in, the quiet one put his pen down. He had not been typing along. He said, more or less: “I am with you on most of this. But when you say ‘headless agent’, can you just explain what is actually in your mind? The version I could explain to my mother would help.”
The room did that small collective lean that means the real question has finally arrived.
What most people mean by headless
In the current industry usage, “headless” mostly means the agent does not come with its own chat window attached.
It is the difference between a Slack bot you talk to and a background process that watches an inbox, a database change, or a message queue. The agent still reasons, still uses tools, still maintains state. It simply does not expect a human to be sitting there typing “please do the thing” every time it should run.
This is useful. It is the agent analogue of a headless CMS. The intelligence is there. The presentation is someone else’s problem. You can trigger it from a cron, a webhook, an event in your ERP, or another piece of software. Many of the production wins people are seeing right now are of this shape: quiet, scheduled or event-driven work that used to require a person to remember to press go.
The sharper distinction that actually matters
The word “headless” hides a more interesting split.
The real question is not only whether there is a UI. It is who decides that this agent should run right now.
There are two rough architectures.
Called agents (sometimes people say “callable”, the transcription heard it as something like Koval) wait for an external decision. A human clicks a button in a dashboard. A cron expression fires at 02:17. An upstream system emits an event and a simple rule says “when this topic appears, invoke InvoiceAgent”. The trigger can be sophisticated in its own right, but the decision to invoke is not coming from an agent that understood the situation. It is coming from a schedule, a form submission, or a static mapping.
Headless agents in the stronger sense are invoked by other agents that do understand the situation. The orchestrator (or a peer) looks at incoming work, current goals, available context, and previous outcomes, and concludes that a particular specialist capability is the right next move. The call itself is an act of judgment, not configuration.
In the first case, the agent is a sophisticated function. In the second, the agent is participating in a small society of agents that can ask each other for help without waiting for a human or a timer to notice.
Comparison at a glance
| Dimension | Called Agents | Stronger Headless Agents (agent-invoked) |
|---|---|---|
| Who decides to run? | Human, cron schedule, static rule, or external event | Another agent that understands the current goals and context |
| Predictability | High — every path is pre-wired | Emergent — the agent decides the next step based on what it sees |
| Governance / Audit | Easy: “human decided” column in the risk register | Harder: you need a new line for “the system noticed and woke the specialist” |
| Reaction speed | Limited by how often the trigger fires or a human looks | As fast as the orchestrator can notice and judge |
| Composability | You wire every possible path in advance | Capabilities compose at runtime when the situation calls for it |
| Best suited for | Predictable, highly regulated, repeatable work | Situational, high-variance, time-sensitive work |
A concrete example
Take incoming invoices.
In the called version, every night a job runs. It pulls new PDFs from the mailbox or the shared folder and hands them to the invoice agent. Or a person in finance opens the “Process queue” screen and presses a large friendly button. The agent does excellent work. It extracts, classifies, proposes bookings, flags anomalies. But the decision that “now is the time to look at invoices” was made by a clock or by a human.
In the stronger headless version, an ambient agent watches the same sources continuously. It sees a new batch of documents arrive on a Thursday afternoon during month-end close. It notices the sender patterns, the amounts, the fact that three of them reference the same project code that already has open items. It decides, without being asked, that this is invoice-shaped work worth waking the specialist for. It may even choose which variant of the invoice agent to call, or pass a small packet of already-inferred context so the specialist does not start from a blank sheet.
The specialist agent still does the detailed work. The difference is that the decision to engage it was made by something that could read the room.
Both versions can be completely headless in the UI sense. One of them is also headless in the decision sense.
Invoice processing — side by side
| Flow step | Called version | Stronger headless version |
|---|---|---|
| Trigger | Nightly cron or finance person presses “Process” | Ambient agent continuously watches the same sources |
| Decision to act | Clock or human | Agent notices new batch + month-end signals + project context |
| Context passed to specialist | Whatever the job or button provides | Already-inferred context (sender patterns, amounts, open items) |
| Governance story | ”We scheduled it” or “Finance lead clicked go" | "The orchestrator judged this was invoice-shaped work” |
Why anyone should care
Most teams that ship agents end up needing both patterns.
Called agents are easier to explain to audit, easier to schedule, easier to put a big red “run now” button in front of a risk officer. The risk register likes them.
The two columns that actually matter on the risk register
| Trigger mechanism | ”Human decided” column example | ”Agent decided” column (new line needed) |
|---|---|---|
| Cron or button click | ”Finance lead scheduled the job / clicked Process at 09:15” | — |
| Agent invocation | — | “Ambient orchestrator noticed month-end signals and woke InvoiceAgent. Owner: Platform + finance escalation path” |
Agent-driven invocation is harder to pre-approve because the path is not drawn in advance. The register has to imagine a new line: “the system noticed and woke the right specialist.” Someone still has to initial beside that line when the phone rings. The quiet one knew those columns by heart. He had signed similar things before, back when the only thing that could surprise you was another human.
Agent-driven invocation buys you something different. It buys reaction speed that is not limited by how often your cron runs or how often a human remembers to look. It buys the ability to compose capabilities at runtime instead of wiring every possible path in advance. It is also harder to govern, because the paths are not drawn on a slide before they happen.
Practical takeaway
Most teams end up needing both patterns on the same platform:
- Offer called mode for anything that needs easy pre-approval, clear audit trails, or a big friendly button for risk officers.
- Offer agent-invoked mode for work that benefits from speed and contextual judgment — the kind where “someone was already paying attention.”
The product question is no longer “headless or not”. It is:
Do we give teams the same identity, policy, logging, and review surfaces for both invocation styles?
Some work benefits from being called on purpose.
Some work benefits from being noticed by something that was already paying attention.
The organisations that get this right stop arguing about whether agents are autonomous or not. They start classifying which goals are worth letting another agent wake up a colleague for — and which ones still need an adult to ring the bell.
Field note from the build-in-public log. NDA-safe, no client names, rounded figures only. If this matches what you are seeing, get in touch.