An agent that drafts a communication and an agent that sends it may use similar technology. They do not carry the same responsibility.
The same is true of an agent that recommends a contractor match versus one that approves it, an agent that suggests a code change versus one that merges it, or an agent that flags a compliance issue versus one that takes action on it.
Those differences should determine the system you build.
Before choosing a model, orchestration framework, or deployment platform, an enterprise needs to understand the work the system will perform, the consequences when it gets that work wrong, where human judgment belongs, and which decisions the organization needs to retain control over.
Production readiness starts there. The model and application are only one layer of an agentic system. Workflow logic, safety and performance management, and infrastructure all have to reflect the job, its risks, and the environment in which the system will operate.
The shape of the work determines the shape of the system.
Here are six decisions to make before you start designing the technology.
1. What is this system actually responsible for?
Start by defining the job.
What is the system expected to do? What decisions can it make? What actions can it take? What happens downstream when it acts?
Responsibility increases quickly once an agent moves from producing information to changing the state of a business process.
Drafting a customer communication is one responsibility. Sending it is another. Recommending a transaction is different from executing one. Suggesting a change to a patient record is different from updating it.
That distinction changes the engineering requirements.
A low-consequence workflow may tolerate a broader range of agent behaviour because errors remain reversible and visible to a person. A system taking consequential actions needs stronger controls around intervention, access, auditability, and failure handling.
Nike is a useful example of the lower-consequence end of that spectrum. An LLM classified and tagged more than 6,300 SKUs in a single day, saving hundreds of hours of manual cataloguing. That kind of work creates room for a wider responsibility boundary because the task is bounded and the output can be checked before it creates downstream consequences.
Define three things before architecture begins: what the agent is authorized to decide, what it is authorized to do, and what remains outside its authority.
Together, those decisions form the system's responsibility boundary.
2. Where does human judgment materially improve the outcome?
Map the places where judgment, authority, context, or accountability changes the outcome.
That may be before an irreversible action proceeds, when a case falls outside the conditions the agent was designed to handle, or when performance moves outside an acceptable threshold.
In one marketplace system we built for an American construction company, AI recommends matches between homeowners and contractors while administrators retain final approval. When an administrator rejects a recommendation, the system captures the proposed match, the discrepancy, and the reason. Those decisions can then reveal patterns in the matching logic that need investigation.
The human decision is part of the operating model and also becomes useful feedback for the system.
Before building, create a human judgment map: the decisions that stay with people, the reason each one stays there, and the conditions under which the workflow should reach them.
3. What should happen when the agent is wrong?
This is where the distinction between reliability and safety becomes essential.
Reliability is whether the agent performs its intended task correctly. Safety is what the system does when it doesn't.
Improving reliability matters. It cannot carry the entire production strategy.
The acceptable reliability of an agent depends on the work. A document summarization agent that produces an imperfect result for human review creates a different problem from an agent making a consequential financial decision. The task, the consequences of failure, and who bears them determine what the system needs around the agent.
For each important step in the workflow, decide whether a failure should allow the system to continue, continue with a flag, retry, apply a mitigation, escalate to a person, or stop entirely.
Airbender, our Agentic Performance Management system, uses critical control points for this purpose: selected points in a workflow where behaviour can be observed, evaluated against a rule or threshold, and acted on before a failure travels further.
Not every step needs a control point. The useful ones sit where an undetected error could create a meaningful consequence.
The output of this discussion should be a failure policy: the important failure conditions in the workflow and the response expected for each one.
4. What needs to be observable and controllable?
Agentic workflows may involve multiple agents, tools, data sources, and decisions. A problem introduced early in that chain can move through several steps before becoming visible.
That makes observability a workflow design problem.
Teams need to decide which behaviours matter enough to monitor, where those behaviours can be observed, and what information someone will need when intervention is required.
Airbender's critical control point model gives operators legible checkpoints through a workflow rather than requiring constant monitoring of every action. Performance can be evaluated against defined thresholds, with exceptions automatically surfaced when they need attention.
Define what the people operating the system need to understand: why an action occurred, which decisions need a traceable history, what signals indicate performance is degrading, and where they need the ability to stop or redirect the workflow.
Capture those requirements in a control map: the points in the workflow that need visibility, the signals being monitored, and the action available when something moves outside acceptable bounds.
5. What does the infrastructure need to make possible?
The infrastructure should follow from the operating requirements of the system.
An agentic application might retrieve documents, call internal tools, persist memory, query business systems, act across workflows, or share context with other agents. Each capability creates decisions about access, isolation, data movement, persistence, and deployment.
As the system grows, context becomes one of those infrastructure concerns. A prompt may hold enough information for a narrow workflow, but that approach becomes harder to sustain when more agents, users, and workflows need to make decisions consistently over time.
At that point, the team needs to define what information persists across sessions, what can be shared between agents, what remains isolated to a user or workflow, which sources are authoritative, and how the agent gets the context required for the current task.
Our context lake concept emerged from this problem: a structured, persistent repository of product intent, business rules, and organizational knowledge that agents can query rather than repeatedly infer from prompts, code, or fragmented documentation.
The same logic applies to access controls, isolation, logging, intervention, and runtime controls. Those requirements need to be enforceable by the underlying environment.
Define these as infrastructure requirements before choosing the infrastructure itself.
6. Which decisions does the organization need to preserve?
Some of the easiest architectural decisions to make during a prototype become the hardest to undo later.
The fastest model to integrate, the most convenient managed service, or the platform with the cleanest SDK may be entirely reasonable choices. What matters is understanding which future choices those decisions preserve or constrain.
TOM Design Collective experienced the business side of this problem with its previous operations platform. The platform was closed, had no API, and could no longer be meaningfully extended as the company evolved.
Rangle built DesignDrive as its replacement. A three-person team delivered the MVP in four months, and TOM moved live client work onto the new system.
The change also altered what TOM controlled. The company now controls its codebase, data model, and roadmap, giving it more freedom over what the business can build next.
For agentic systems, this is a useful definition of sovereignty: retaining control over the parts that matter to the business and preserving the ability to make different choices later.
Before committing to the stack, define your sovereignty constraints: where data must live, what components need to remain replaceable, what the organization needs visibility into, and which architectural choices cannot become permanent dependencies by accident.
The shape of the work determines the shape of the system
You can now enter the architecture conversation with six concrete inputs:
- Responsibility boundary: what the agent is authorized to decide and do.
- Human judgment map: where people remain involved and why.
- Failure policy: what should happen when the agent is wrong.
- Control map: what needs to be observed, measured, stopped, or escalated.
- Infrastructure requirements: what the environment must support and enforce.
- Sovereignty constraints: which choices the organization needs to preserve over time.
Those decisions will look different for every system.
A marketing workflow producing drafts for review should not carry the same architecture as a system making regulated decisions. A recommendation engine should not automatically inherit the same control model as a system executing transactions.
The technology should be shaped by the responsibility the system is taking on.
These decisions will evolve as teams build, test, and learn. The point is to bring responsibility, safety, human judgment, infrastructure, and control into that iteration from the beginning, rather than treating them as production concerns that arrive later.
The fastest route to a working agent is increasingly short. The harder work is evolving the system around it so the organization understands what it can do, what happens when it is wrong, where people remain accountable, and how much control the business retains as the system evolves.
See what this looks like in practice
These decisions become much more concrete when you see the architecture behind them.
On September 30, we're hosting The Infrastructure Behind Production-Ready Enterprise AI, where we'll build and deploy a production-ready enterprise application live and walk through the infrastructure and architectural decisions that make it possible.
