The most common question we get when people first encounter Atlantic is: why not one general-purpose agent instead of multiple role-specific ones? It seems simpler. A single agent that can do anything across your company has obvious appeal. The answer is that general-purpose agents and role-specific agents are solving different problems, and for operational workflows at growing companies, the role-specific model produces more reliable behavior at lower configuration complexity. This post explains why.
What a general-purpose agent actually means in practice
A general-purpose agent, as the term is usually used, is an agent with a broad system prompt and access to many tools, capable of handling a wide range of requests through a conversational or task interface. You tell it what to do, and it figures out how to do it using the tools it has available.
This works well for tasks that are well-specified at request time: "summarize this document," "draft an email responding to this thread," "look up this data and format it as a table." For these tasks, the general-purpose model is appropriate because the task is fully specified when it is submitted and the consequences of errors are bounded by the scope of a single request.
For operational workflows, the situation is different. An operational workflow is not a single request. It is a recurring pattern of actions that runs on a schedule or in response to triggers, takes inputs from multiple systems, produces outputs in multiple systems, and has downstream consequences that can persist for days or weeks. The finance agent that processes invoices is not doing one task. It is running a workflow that touches your accounting system, your email, and your vendor relationships continuously.
Asking a general-purpose agent to manage a continuous operational workflow without a defined scope and without explicit escalation rules is asking it to make judgment calls it is not equipped to make reliably. The agent has no stable definition of what the finance function should do, what it should not do, and when human judgment is required. That lack of definition is fine when a human is specifying the task fresh each time. It is not fine when the agent is operating autonomously over time.
How the role-based model differs
In the role-based model, each agent is defined not by its general capabilities but by its specific function within the organization. A Finance agent has a defined scope: the actions it can take, the systems it has access to, the conditions under which it escalates to a human, and the owner who is responsible for its behavior. These constraints are not limitations imposed on an otherwise general capability. They are the definition of the role itself.
This maps to how roles work for human employees. When you hire a finance coordinator, they do not show up with infinite scope and undefined authority. They have a job description: specific responsibilities, specific systems access, specific escalation paths when something is outside their authority. The clarity of that definition is what makes it possible for them to do their job reliably without constant supervision.
The role-based agent model applies the same structure to AI agents. The Finance agent in Atlantic has the equivalent of a job description: these are the workflows it handles, these are the systems it can access and what it can do in each, this is when it escalates. That clarity is what allows it to run reliably in production.
Why constraints produce better behavior, not worse
A common intuition is that more capability is better: an agent with broader permissions and a less constrained scope should be able to do more useful things. This intuition fails in production operational contexts for a specific reason.
Broader permissions and less constrained scope increase the space of actions the agent considers when processing any given input. That larger action space means more opportunities for the agent to take an action that is technically within its permissions but wrong for the specific context. The operations agent that has permission to send emails on behalf of the company could, in theory, send an email to a vendor about a matter that should have gone to a different contact, or send an email at an inappropriate time, or send something that a human would have recognized as needing a different tone. It is not that the agent lacks capability. It is that it lacks the context to make the right judgment in every case.
The role-based constraint prevents this by defining not just what the agent can do but what it should do. The agent's action space is bounded by the role definition. Within that bounded space, it operates reliably. Outside that space, it escalates. This combination of reliability within scope and clear escalation at scope boundaries is what makes operational workflows trustworthy in production.
The tradeoff: setup specificity
The role-based model requires more upfront specificity than a general-purpose agent. You have to define the scope, configure the integrations, and set the escalation rules before the agent is useful. This takes time, and it requires the person configuring the agent to understand the workflow well enough to define its boundaries.
We do not think this is a significant downside for the teams Atlantic is designed for. Operations teams at growing companies have well-defined workflows. An ops director knows what their finance workflow looks like. The configuration process requires them to make that knowledge explicit, which is itself useful: teams often discover implicit process knowledge they had not articulated, and articulating it produces a better-designed agent and a better-understood process.
What we are not claiming is that the role-based model is the right architecture for all agent use cases. It is not. For creative tasks, for exploratory research, for ad hoc analysis, a general-purpose agent or a chatbot-style interface is appropriate. The role-based model is specifically optimized for operational workflows that need to run reliably and continuously, with appropriate human oversight, without requiring constant human specification. For that use case, the constraints are features.
