Before reading this page, it helps to understand what an agent is and how it is structured. If you haven’t already, read What is an agent? and the Agent Structure overviewBefore reading this page, it helps to understand what an agent is and how it is structured. If you haven’t already, read What is an agent? and the Agent Structure overview.
What you are setting up
Your starting point is a minimal but complete unit: a single department — call it Department A — running its own agent runtime on a dedicated machine, VM-1. This setup is self-contained. The agent on VM-1 handles only the work that belongs to Department A. It reads inputs that are relevant to that department, applies Department A’s documented procedures, and produces outputs in a defined format. This single-department unit is the pattern you will replicate for every subsequent department. Getting it right here means every future expansion follows the same tested model rather than being built from scratch.The three things you define first
Before any agent can run, three things need to be in place. These are not technical configuration details — they are decisions about how Department A actually operates.1
The department's SOPs
SOPs — standard operating procedures — are the rules your agent follows. They describe what the department does, in what order, under what conditions, and what happens at each decision point.For your first agent, start with the most repetitive, high-volume workflow in Department A. Document it as a sequence of steps: what triggers the workflow, what information is needed, what decisions are made, and what the output looks like. This written procedure becomes the agent’s instruction set.
2
The input interface
Define what information arrives at VM-1, in what format, and from where. Your agent needs a consistent, predictable input stream to work reliably.For a first deployment, a simple file-based or message-based input is sufficient. A directory that receives incoming JSON files, or a lightweight queue that Department A’s existing systems write to, is a practical starting point. The format of each input message should be agreed and documented — field names, data types, and expected values — before the agent runtime is configured.You are not connecting to your ERP, CRM, or other external systems yet. Those integrations come later, once the core runtime is validated. At this stage, input can come from a manual process or a simple export from an existing system.
3
The output interface
Define what the agent produces and where it sends it. An output is typically a structured message or file — a decision, a summary, a completed record, or a handoff instruction — written in the same JSON format that the rest of your future infrastructure will expect.For VM-1, output might write to a monitored folder, post to a shared log, or update a simple status record. The important thing is that the format is defined up front and does not change between iterations. Consistency here is what makes it possible to connect Department A’s output to Department B’s input later without rebuilding anything.
What VM-1 looks like at this stage
Once the three definitions above are in place, VM-1 hosts a lightweight agent runtime. This runtime is not a complex platform — it is a contained process that:- Watches for incoming inputs matching the defined format
- Applies Department A’s SOPs to each input
- Produces structured output in the agreed format
- Logs what it did and flags anything it could not process
Keep the scope narrow
One workflow, one trigger type, one output format. The value of the first deployment is proving the pattern works — not automating everything at once.
Plan for review
Before connecting VM-1’s output to any downstream system, your team should review a batch of real outputs manually. This builds confidence and surfaces any SOP gaps early.
What happens after VM-1 is running
A single validated department runtime is the foundation for everything that follows. Once Department A is operating reliably on VM-1, the infrastructure expands in stages:- Add a second department — set up VM-2 using the same runtime pattern. Define its SOPs, input format, and output format independently. At this stage, the two departments are still isolated from each other.
- Connect departments via message exchange — once both runtimes are validated, link them so that the output of one can become the input of the other. This is typically a shared message directory or lightweight queue that both VMs can read from and write to.
- Integrate external systems — once the inter-department messaging is stable, begin connecting your existing systems. ERP adapters, CRM connectors, and legacy system bridges attach at defined input and output points without changing the runtime itself. See Integrations for how those connectors are structured.
- Integrate external systems — once the inter-department messaging is stable, begin connecting your existing systems. ERP adapters, CRM connectors, and legacy system bridges attach at defined input and output points without changing the runtime itself. See Integrations for how those connectors are structured.
- Move toward event-driven exchange — as the number of departments and message volumes grow, the file-based exchange model can be replaced with an event streaming layer. The agent runtimes do not change; only the transport between them is upgraded.
This staged model is intentional. Each phase validates before expanding. You are never in a position where a change to one department’s setup breaks another, because the interfaces between them are explicit, versioned, and agreed before either side connects.
Before you move on
A working VM-1 deployment means you can answer yes to all of the following:- Department A’s core workflow is documented as a runnable SOP
- The input format for VM-1 is defined and consistently produced
- The output format is defined and has been reviewed by your team against real examples
- The agent runtime on VM-1 produces correct output for the common case, and flags exceptions rather than silently failing
- You have a clear picture of which department or system will receive VM-1’s output in the next phase
Agent structure
Understand the components that make up a running agent — inputs, reasoning, actions, and the interfaces between them.
What is an agent?
A plain-language explanation of what an agent is, how it differs from simpler automation, and what it can and cannot do.
What you are setting up
Your starting point is a minimal but complete unit: a single department — call it Department A — running its own agent runtime on a dedicated machine, VM-1. This setup is self-contained. The agent on VM-1 handles only the work that belongs to Department A. It reads inputs that are relevant to that department, applies Department A’s documented procedures, and produces outputs in a defined format. This single-department unit is the pattern you will replicate for every subsequent department. Getting it right here means every future expansion follows the same tested model rather than being built from scratch.The three things you define first
Before any agent can run, three things need to be in place. These are not technical configuration details — they are decisions about how Department A actually operates.1
The department's SOPs
SOPs — standard operating procedures — are the rules your agent follows. They describe what the department does, in what order, under what conditions, and what happens at each decision point.For your first agent, start with the most repetitive, high-volume workflow in Department A. Document it as a sequence of steps: what triggers the workflow, what information is needed, what decisions are made, and what the output looks like. This written procedure becomes the agent’s instruction set.
2
The input interface
Define what information arrives at VM-1, in what format, and from where. Your agent needs a consistent, predictable input stream to work reliably.For a first deployment, a simple file-based or message-based input is sufficient. A directory that receives incoming JSON files, or a lightweight queue that Department A’s existing systems write to, is a practical starting point. The format of each input message should be agreed and documented — field names, data types, and expected values — before the agent runtime is configured.You are not connecting to your ERP, CRM, or other external systems yet. Those integrations come later, once the core runtime is validated. At this stage, input can come from a manual process or a simple export from an existing system.
3
The output interface
Define what the agent produces and where it sends it. An output is typically a structured message or file — a decision, a summary, a completed record, or a handoff instruction — written in the same JSON format that the rest of your future infrastructure will expect.For VM-1, output might write to a monitored folder, post to a shared log, or update a simple status record. The important thing is that the format is defined up front and does not change between iterations. Consistency here is what makes it possible to connect Department A’s output to Department B’s input later without rebuilding anything.
What VM-1 looks like at this stage
Once the three definitions above are in place, VM-1 hosts a lightweight agent runtime. This runtime is not a complex platform — it is a contained process that:- Watches for incoming inputs matching the defined format
- Applies Department A’s SOPs to each input
- Produces structured output in the agreed format
- Logs what it did and flags anything it could not process
Keep the scope narrow
One workflow, one trigger type, one output format. The value of the first deployment is proving the pattern works — not automating everything at once.
Plan for review
Before connecting VM-1’s output to any downstream system, your team should review a batch of real outputs manually. This builds confidence and surfaces any SOP gaps early.
What happens after VM-1 is running
A single validated department runtime is the foundation for everything that follows. Once Department A is operating reliably on VM-1, the infrastructure expands in stages:- Add a second department — set up VM-2 using the same runtime pattern. Define its SOPs, input format, and output format independently. At this stage, the two departments are still isolated from each other.
- Connect departments via message exchange — once both runtimes are validated, link them so that the output of one can become the input of the other. This is typically a shared message directory or lightweight queue that both VMs can read from and write to.
- Integrate external systems — once the inter-department messaging is stable, begin connecting your existing systems. ERP adapters, CRM connectors, and legacy system bridges attach at defined input and output points without changing the runtime itself. See Integrations for how those connectors are structured.
- Integrate external systems — once the inter-department messaging is stable, begin connecting your existing systems. ERP adapters, CRM connectors, and legacy system bridges attach at defined input and output points without changing the runtime itself. See Integrations for how those connectors are structured.
- Move toward event-driven exchange — as the number of departments and message volumes grow, the file-based exchange model can be replaced with an event streaming layer. The agent runtimes do not change; only the transport between them is upgraded.
This staged model is intentional. Each phase validates before expanding. You are never in a position where a change to one department’s setup breaks another, because the interfaces between them are explicit, versioned, and agreed before either side connects.
Before you move on
A working VM-1 deployment means you can answer yes to all of the following:- Department A’s core workflow is documented as a runnable SOP
- The input format for VM-1 is defined and consistently produced
- The output format is defined and has been reviewed by your team against real examples
- The agent runtime on VM-1 produces correct output for the common case, and flags exceptions rather than silently failing
- You have a clear picture of which department or system will receive VM-1’s output in the next phase
Agent structure
Understand the components that make up a running agent — inputs, reasoning, actions, and the interfaces between them.
What is an agent?
A plain-language explanation of what an agent is, how it differs from simpler automation, and what it can and cannot do.