Most teams building with AI right now have an automation layer. It runs on a schedule or fires on a webhook. It has a prompt, maybe some repo access, maybe a tool or two. It works. And it is architecturally wrong.
The problem is not that automations are broken. The problem is that calling them automations constrains how your team thinks about what they can do. An automation is a cron job with a language model attached. An agent is something fundamentally different — and the distinction is not semantic. It is structural.
When you build an automation, you bundle too many concerns into one object. Trigger logic, prompt, tools, model selection, sandbox, reasoning level — all of it in one flat construct. That works when you have five automations. It falls apart at fifty. You cannot reuse them. You cannot version them independently. You cannot invoke the same logic from a different context.
Here is what needs to happen: the agent becomes its own primitive. It has a prompt, skills, MCP connections, a model, a reasoning level, sandbox configuration. It exists independently of when or how it gets invoked. Triggers — schedules, webhooks, events — become a separate concern. A trigger creates a session that uses an agent. The agent does not know or care how it was invoked. Automations stop being a category of system and become what they always were: one of several ways to start a session.
This is the unlock. Once the agent is a clean primitive, you can invoke any agent inside any session — by cron, by human, by another agent. The trigger is incidental. The agent is the unit of capability. Build that distinction in early or pay for it later.
Sources
Related Essays
Sessions Replace Tasks, Runs, and Threads
When the same object has three names, your architecture is drifting. Tasks, runs, threads, chats — all of it is just a session. One container, many shapes of work.
Agents Are Software, Not Prompts
The industry treats agents as a new category. They are not. Agents are software, and the same engineering principles that have always mattered still apply.
The Declarative Atomic Agent
An atomic agent is a single declarative spec — input, output, purpose, constraints. That property is what makes the mesh composable, auditable, and cheap to optimize.
Key takeaways
- Automations bundle too many concerns into one flat construct — trigger, prompt, tools, model, sandbox.
- The agent should be its own primitive, independent of how it gets invoked.
- Triggers become a separate concern. Crons, webhooks, and humans all start sessions that use agents.
FAQ
What is wrong with automations as an architectural unit?
They bundle trigger logic, prompt, tools, model selection, and sandbox into one flat object. That works for five automations and falls apart at fifty. You cannot reuse them, cannot version them independently, and cannot invoke them from new contexts.
How does treating the agent as a primitive change things?
The agent has a prompt, skills, MCP connections, model, reasoning level, and sandbox configuration. It exists independently of when it gets invoked. The same agent can run on a 9 AM cron, get called by a human in a session, or get invoked as a sub-task by another agent.