How to design agentic workflows: from business process to production-grade AI agents

The conversation about AI agents usually begins in the wrong place. A company sees an impressive coding agent, a research agent, or a demonstration of a model operating software, and someone asks: where can we build an agent in our company? That question already contains an architectural assumption — and it is the wrong one.

A better question is: what work are we trying to improve, how does that work actually happen today, and which parts of it genuinely benefit from machine intelligence and autonomy? The difference looks subtle. Architecturally it changes almost everything. A production-grade agentic system is rarely a model sitting in the middle of a business process doing everything. It is almost always a combination of conventional software, deterministic rules, calculations, APIs, model calls, reusable procedural knowledge, tools, orchestration, agents, and humans — assembled so that each piece of work is performed by the mechanism best suited to it.

The purpose of agentic architecture is to assign the right kind of intelligence to the right kind of work.

That principle is the spine of this guide. We will move from the business workflow all the way down to the runtime beneath an agent: how to discover and decompose real work, how to classify what each task needs, how tools differ from Skills, where MCP fits, how context differs from memory and both differ from state, what an agent harness actually does, when multi-agent architecture earns its cost, why evaluations must be designed before the system, how observability differs from evaluation, and how an agent moves from a developer’s laptop into a production enterprise environment. By the end you will have something considerably more useful than a definition of an AI agent. You will have a method for turning real organizational workflows into reliable agentic systems.

The running example throughout is an FMCG manufacturer that runs hundreds of retailer promotions every month. The mechanics are specific to consumer goods; the architecture is not. Substitute claims adjudication, loan origination, clinical coding, or field service and the shape of the answer barely changes.

Before designing an agent, understand the workflow. Suppose the process is promotion performance analysis. At first glance this sounds like an excellent candidate for an “AI promotion agent.” But that description hides almost all of the architecture. What actually happens is closer to this:

1. 01A promotion finishes and the sales data lands.
2. 02Someone retrieves the promotion calendar and the planned mechanics.
3. 03Someone retrieves the baseline — the sales that would have happened anyway.
4. 04Someone checks actual sales at the retailer and store level.
5. 05Incremental volume is calculated.
6. 06Promotional spend is calculated, including fixed fees and unclaimed accruals.
7. 07Gross margin impact is calculated.
8. 08Distribution and on-shelf availability are checked.
9. 09Pricing compliance is checked — did stores actually implement the promoted price?
10. 10Results are compared with previous comparable promotions.
11. 11A category or trade marketing manager investigates anything unusual.
12. 12A conclusion is written.
13. 13Recommendations are created.
14. 14Someone with authority approves future actions.
15. 15Results are stored so the next planning cycle can use them.

Say “build an agent that analyzes promotions” and you collapse fifteen distinct operations into one conceptual box. Some of them require reasoning. Most do not. That distinction is where agentic architecture begins.

Workflow discovery: mapping the operating system around the work

The first stage is workflow discovery. You are not inventing an AI architecture yet; you are understanding reality. For each workflow, map at least the following — and map what actually happens, not what the process document says happens.

One more discovery habit pays for itself repeatedly: ask people which spreadsheet they maintain privately, and who they message when the system is wrong. Shadow work is where the real business logic lives. It is also, reliably, the part missing from every process diagram.

Once the workflow is understood, break it into smaller units. A useful rule: if two parts of a workflow could reasonably be implemented differently, treat them as separate architectural units. For the promotion example:

Now architecture becomes possible, because Task D and Task G have almost nothing in common computationally. Subtraction is subtraction. Working out why a promotion missed plan by sixteen points is an investigation whose path cannot be written down in advance.

It is worth annotating each task with four more attributes before you choose mechanisms, because they drive the controls rather than the architecture: frequency (once a quarter or four hundred times a month), latency tolerance (does an answer in twenty minutes have the same value as one in twenty seconds?), consequence (what happens if this step is wrong?), and reversibility (can the mistake be undone, and by whom?). A task that is high-frequency, low-consequence, and reversible is the ideal first candidate for autonomy. A task that is rare, high-consequence, and irreversible is where humans stay, possibly forever.

For every task, ask one question: what is the simplest reliable mechanism capable of doing this work? There are only a handful of honest answers.

The automation spectrum

It helps to think of architecture as a spectrum rather than a binary. At one end sits traditional deterministic software. At the other, high-autonomy agents. Everything interesting lives in between, and you should move down the ladder only when the problem forces you to.

This ordering prevents the most common failure in enterprise AI projects: turning everything into an agent because agents are fashionable. Autonomy is an architectural resource with a price — more tokens, more latency, more failure modes, more to trace, more to govern. Spend it where it creates value.

Four kinds of intelligence in one business process

Return to promotion analysis and watch the mechanism change four times inside a single workflow.

Calculating uplift is a formula: actual sales minus expected baseline sales. Once the baseline methodology has been agreed — and agreeing it is a business decision, not a technical one — this should be deterministic. Python, SQL, a calculation service, or the existing analytics platform. There is no benefit in asking a language model to reason about subtraction, and considerable risk in letting it.

Summarizing performance is a language transformation. Given uplift +17%, ROI 1.42, margin impact +€82,000, availability 96%, and promotional compliance 88%, produce a concise executive summary. A single model call is enough. No agent loop is necessary, no tools, no planning. Adding them would only add cost and variance.

Investigating underperformance is different in kind. Suppose the system detects that uplift was 2% against an expected 18%. The investigation may need to establish whether availability was poor, stores received stock late, the retailer implemented the price correctly, a competitor ran a stronger promotion, another SKU cannibalized the volume, the baseline was wrong, weather moved the category, media activation was delayed, distribution fell, or a regional anomaly distorted the national number. The correct path depends on what the system discovers as it goes. That is what an agent is for: formulate hypotheses, choose which data to inspect, call the appropriate tools, interpret results, reject hypotheses, form new ones, and synthesize a conclusion.

Approving a €2 million increase in promotional investment is not a reasoning problem at all. It is a question of authority and accountability. Depending on the governance model, it requires a named human. So one business workflow contains code, then a model call, then an agent, then a human — and that layering is what good agentic architecture usually looks like.

When does a task genuinely need an agent?

A task becomes a strong agent candidate when several of these characteristics appear together. One alone is rarely enough.

• The path cannot be known in advance. The next action depends on what the previous one revealed.
• Multiple tools may be required. Something has to decide which, and in what order.
• The task requires iterative reasoning. Observe, think, act, observe, revise — several rounds.
• Intermediate results change the plan. New evidence should change the strategy, not just the wording.
• The task contains ambiguity. Incomplete information must be interpreted rather than rejected.
• Failure recovery matters. A tool call fails and the system must find an alternative route.
• The task is outcome-oriented. The objective is known; the exact sequence of operations is not.
• The environment can give feedback. There is something to observe that tells the agent whether it is getting warmer. Without feedback, an agent is just an expensive guess.

Which gives a compact working definition: an agent is an LLM-based system that dynamically chooses and executes actions, usually through tools, in pursuit of an objective. Anthropic’s context engineering guidance puts it even more tersely — models autonomously using tools in a loop.

The rise of agents does not reduce the importance of normal software engineering. It increases it. Agents perform far better when surrounded by reliable deterministic systems, because every guaranteed operation is one less thing the model has to get right. Consider a set of operations that should behave identically every time:

calculate_margin()          check_inventory_threshold()
calculate_uplift()          query_sales_database()
validate_sku_id()           convert_currency()
check_permission()          validate_email_address()

If the same numbers go into calculate_margin(), the same number must come out. We do not want an agent creatively interpreting arithmetic, and we do not want a promotion evaluation whose ROI shifts by two points because the model was sampled at a different temperature. This yields an important architectural idea: the more deterministic work you can safely remove from the agent’s reasoning burden, the more attention the agent can spend on genuine reasoning. Reliability and quality improve together, which is unusual and worth exploiting.

There is a second, quieter benefit. Deterministic functions are testable in the ordinary way. A promotion ROI service can have unit tests, a changelog, and an owner in finance. Move that logic into a prompt and you have replaced a tested function with an untested — and untestable — paragraph.

Where LLM workflows fit

Between deterministic software and agents sits a category teams routinely skip past. Consider this sequence: extract information, classify the document, summarize it, generate structured JSON. Every step involves a model. But the path is fixed — the first step always leads to the second, and no model ever decides what to do next. That is an LLM workflow, and a great deal of enterprise value lives there rather than in agents.

Anthropic documents several workflow patterns worth knowing by name: prompt chaining (decompose into fixed sequential steps), routing (classify, then dispatch to a specialized branch), parallelization (run independent subtasks concurrently and aggregate), orchestrator-worker (a central call decomposes and delegates), and evaluator-optimizer (generate, critique, revise). The first four are workflows. Only when the orchestrator’s decomposition is genuinely dynamic does it cross into agent territory.

Neither architecture is superior. They solve different problems, and most real systems contain both: a deterministic intake, an agentic middle where the uncertainty lives, and a deterministic execution tail where the consequential actions happen.

Once tasks are classified, the next question is what capabilities the system needs. This is deliberately different from asking what agents we need. Group them by verb:

• Read. POS data, inventory, promotion calendar, retailer master data, pricing, historical promotion results, competitor information.
• Compute. Baseline, uplift, ROI, anomaly detection, cannibalization.
• Reason. Interpret unusual patterns, compare hypotheses, identify causal candidates, choose investigation paths.
• Write. Create the report, update the database, store the learning, draft a recommendation.
• Communicate. Send a Teams message, generate an email, notify a manager, request approval.

Now each capability maps to an implementation — and the map itself becomes one of the most useful artifacts in the whole project.

The capability map prevents architecture discussions from collapsing into model discussions. The question moves from “which model should we use?” to “what must the system be capable of doing, and which mechanism should provide each capability?” The second question is answerable, assignable, and testable. The first is mostly a preference.

The source-of-truth map

One artifact belongs next to the capability map and is almost always missing: a statement of which system is authoritative for which fact. Access to data is not the same thing as operationally usable data. A promotion agent can technically read five systems that each contain a number called “promotional spend” and none of them agree.

Three lessons hide in that table. First, one vector database should not impersonate every knowledge source; contracts, transactions, policy, and market data have different owners, permissions, and update rhythms. Second, identifier mismatch is the single most common reason enterprise agents produce confidently wrong numbers — retailer SKU codes, internal material numbers, banner versus legal entity, and category hierarchies rarely line up, and an agent that cannot resolve entities will silently compare the wrong things. Third, freshness has to be a value the agent can see: a tool that returns spend without saying whether accruals have settled invites an ROI figure that will be revised next month.

Add one more definition while you are here: evidence sufficiency. What is the minimum set of facts that must be present before a conclusion is allowed? Without it, an agent will cheerfully conclude from whatever it happened to retrieve. With it, “insufficient evidence, here is what is missing” becomes a valid — and often correct — output.

A language model by itself generates tokens. To affect the world it needs tools — callable capabilities exposed to the model, with names, inputs, and outputs it can reason about. Think of the model as intelligence and tools as the operational surface that intelligence acts through. A useful shorthand: tools are what the agent can do.

Tool design matters more than most teams expect. Anthropic has emphasized that agent performance depends heavily on the quality and clarity of the tools exposed to the system. A badly designed tool interface can make a capable model look incompetent — and, more insidiously, make a capable model look unreliable, because it will succeed on the calls it happens to guess correctly and fail on the rest.

Two tool contracts, one enormous difference

Compare a poor tool with a good one. The poor version:

query_database(input)

    what should input contain?
    which database?  which schema?
    what output format?  what permissions?
    what happens when it fails?

The better version:

get_promotion_sales(
    promotion_id: string,      # e.g. "P-1134"
    retailer_id: string,       # e.g. "R-21"
    start_date: date,
    end_date: date
) -> PromotionSales

{
  "promotion_id": "P-1134",
  "retailer_id": "R-21",
  "units": 82412,
  "revenue": 216398,
  "currency": "EUR",
  "data_completeness": 0.997,
  "as_of": "2026-03-14T06:00:00Z"
}

The second version is not merely tidier. It tells the agent what it is allowed to ask for, what it will get back, in what units, and how much of the data is actually present — so the agent can decide for itself whether the evidence is sufficient. Good tools generally have:

• Clear names that describe the business operation, not the internal endpoint.
• Precise descriptions written for a competent new analyst, including when not to use the tool.
• Constrained inputs — enums, identifiers, explicit units, date types — so the space of wrong calls is small.
• Predictable, structured outputs with a stable schema.
• Explicit error states that say what went wrong and what to try instead, rather than a stack trace or a bare “error”.
• Narrow permissions — the tool, not the prompt, is where authority is enforced.
• Separation of read from write. Information tools and action tools should never be the same tool with a flag.
• Idempotency on writes. Every action tool that changes the world should accept a client-supplied key so a retry cannot create a second reservation, a second email, or a second payment.
• Token-efficient responses. A tool that returns ten thousand rows when the agent needed an aggregate is a context problem disguised as an integration.

APIs, MCP, CLI, and custom tools

Business systems expose capability through many interfaces: REST APIs, GraphQL, SDKs, SQL, command-line interfaces, filesystem access, browser automation, custom functions, and MCP servers. These are related but not equivalent, and conflating them causes real confusion in design reviews.

One API can become three tools, or none. Three APIs can be composed into one tool. The tool boundary is a design decision about what the agent should be able to express, not a mirror of your service catalogue.

Where MCP fits

The Model Context Protocol matters in agentic architecture because it standardizes how AI applications connect to external capabilities and information. Conceptually it sits between the enterprise system and the agent runtime:

Enterprise system  (SAP, Snowflake, Jira, Drive, Salesforce)
        |
        v
   MCP server        exposes tools, resources, prompts
        |
        v
 AI host / runtime   discovers and permissions capabilities
        |
        v
      Agent          calls what it is authorized to call

Without a standard interface, every AI environment needs its own bespoke connector to every system — an integration matrix that grows multiplicatively and rots quietly. With MCP-compatible infrastructure, a larger share of that layer becomes reusable across agent platforms. MCP should therefore be thought of as part of the connectivity architecture around agents, not as a replacement for APIs or the business systems themselves.

Tools are frequently confused with Skills, and the distinction is worth getting right because it determines where your company’s methodology lives.

Tool = capability. Skill = know-how.

Imagine a new trade marketing analyst joins the company. You give her access to SAP. That is analogous to providing a tool. But SAP access does not teach her how to conduct excellent promotion analysis. For that you also give her methodology documents, analytical principles, evaluation templates, company-specific definitions, category benchmarks, worked examples, and escalation guidelines. That bundle is analogous to a Skill.

Anthropic’s Agent Skills architecture makes this concrete: filesystem-based packages containing instructions, metadata, and optional supporting resources such as scripts, templates, and reference material — loaded when relevant rather than occupying the model’s context continuously. A promotion analysis Skill might look like this:

promotion-analysis/
|
|-- SKILL.md                    # when to use this, and how
|-- methodology.md              # our baseline definition
|-- promotion-types.md          # mechanics taxonomy
|-- benchmark-ranges.md         # what "good" looks like by category
|-- examples/
|   |-- successful-promo.md
|   \-- failed-promo.md
|
\-- scripts/
    |-- calculate_uplift.py
    \-- validate_inputs.py

SKILL.md encodes the procedure: verify baseline quality, check data completeness, calculate incrementality, investigate availability, investigate price compliance, inspect cannibalization, compare historical analogues, classify the likely cause, produce a recommended action. That is procedural knowledge — the thing a good analyst carries in their head and a new one takes two years to acquire.

The combination with deterministic scripts is what makes this powerful. The Skill tells the agent when and why to calculate uplift. calculate_uplift.py determines how the arithmetic executes reliably. Judgment and computation are separated, and each is owned by the discipline best equipped to maintain it.

Progressive disclosure

Skills introduce a second architectural idea that generalizes far beyond Skills: progressive disclosure. You do not want the full contents of two hundred Skills loaded into every request. Instead, capability is revealed in tiers.

Anthropic documents exactly this tiering: lightweight metadata is available first, Skill instructions load when triggered, and additional resources or scripts are accessed only when required. Economically this is what makes an organizational Skill library possible at all — the marginal cost of the two-hundredth Skill is a few dozen tokens of description, not a few thousand tokens of instruction.

This is also where the strategic opportunity sits. An FMCG company holds decades of expertise in senior employees, PowerPoints, SOPs, Excel templates, unwritten conventions, and meeting routines. Skills provide one mechanism for turning part of that operating knowledge into reusable, machine-readable procedural knowledge: how we evaluate promotions, how we calculate baseline, how we prepare retailer negotiations, how we investigate service-level failures, how we prepare category reviews. That library is an organizational capability layer — and unlike a model, it is yours.

Early generative AI development focused on the prompt. Agentic systems introduce a larger question: what information should the model have available at each moment of the task? That is context engineering. Anthropic describes it as managing the information available to the model across system instructions, tool definitions, retrieved information, conversation history, and other runtime inputs — with an emphasis on just-in-time retrieval rather than preloading everything.

A model’s active context at any moment might contain:

System instructions
  + user request
  + current workflow state
  + relevant Skill
  + tool definitions
  + retrieved documents
  + recent tool results
  + relevant memory
  + conversation history

More context does not mean better reasoning

Suppose an organization holds eight million documents, seventy thousand product records, twelve years of sales data, forty thousand historical promotions, six hundred policies, and three hundred Skills. Obviously you cannot stuff that into every interaction. Less obviously, you should not stuff in as much as technically fits. Even with a very large context window, irrelevant information costs you:

• Money. Every token is billed, on every step of the loop.
• Latency. Large contexts are slower to process, and agents process them repeatedly.
• Relevance. The signal-to-noise ratio falls as volume rises.
• Attention. Retrieval within a long context degrades; the model can look straight past the one line that mattered.
• Coherence. Conflicting instructions from different documents produce unpredictable precedence.
• Freshness. Preloaded snapshots go stale mid-task; inventory from four steps ago is a different number now.

The design goal is not maximum context. It is the right context, in the right order, at the right moment.

Just-in-time context, in practice

Watch how little the promotion agent needs to begin. It starts with the case, not the corpus:

Promotion ID: P-212
Retailer:     Albert Heijn
Country:      Netherlands
Goal:         investigate underperformance

It does not need every previous promotion, the full pricing database, every company policy, every retailer contract, or twelve years of weather history. It reasons: first I need sales and baseline performance, and calls get_promotion_performance(P-212). The result shows poor uplift. It reasons: availability could explain this, and calls get_availability(P-212). Availability looks normal. It reasons: check promotional price compliance, and continues. The system incrementally builds context around the investigation, and the context it ends with is a record of the reasoning rather than a dump of the data lake.

For long-running work there is a corollary. Investigations that run for dozens of steps will eventually exceed any window, so the harness needs a compaction strategy: summarize completed sub-investigations into durable findings, keep the evidence identifiers rather than the evidence, and write anything that must survive into state rather than hoping it stays in the transcript. An agent that has forgotten the first half of its own investigation will happily repeat it.

The distinction that prevents operational accidents

Context, memory, and state are used interchangeably in conversation and must not be conflated in architecture.

Context is what the model can currently see: active instructions, recent tool results, the current conversation, retrieved documents, the loaded Skill. Its lifecycle is measured in inference steps or a session.

Memory is information persisted so that it may be retrieved later — “this retailer frequently executes price changes two days late,” “this user prefers promotion reports in a particular format,” “this category shows strong weather sensitivity.” It persists across sessions, and it should be treated as a stored claim rather than a fact: every memory needs a source, a timestamp, and a way to be corrected or expired.

State describes the authoritative current condition of the workflow. It is not fuzzy and it is not optional:

promotion_id:      P-212
investigation:     awaiting finance validation
stage:             6 of 9
approval_status:   pending
approval_request:  APR-482
assigned_reviewer: Finance Director

Treating important workflow state as fuzzy agent memory creates serious operational problems. Imagine a procurement agent negotiating with suppliers. If it forgets whether a purchase order has already been issued, the consequence is not a poor answer — it is a duplicate commitment. Facts such as order created, payment approved, contract signed, invoice received, shipment dispatched belong in deterministic system state, which the agent reads and updates through controlled tools.

A practical memory taxonomy

Different kinds of memory deserve different storage, retrieval, and retention strategies. A workable mental model:

The taxonomy matters because the failure modes differ. Stale semantic memory produces confidently wrong classifications. Stale episodic memory produces false analogies. Stale procedural memory produces consistent, methodical, organization-wide error — which is the most expensive kind, because it looks like rigor.

Here we reach one of the most under-discussed concepts in agent engineering. The model is not the agentic system. Around it sits the infrastructure that lets it operate — the agent harness, sometimes called the scaffold. Anthropic defines it as the system enabling a model to act as an agent: processing inputs, orchestrating tool calls, and returning results.

The model provides intelligence. The harness makes that intelligence operational.

Depending on the architecture, the harness manages model calls, system instructions, the tool registry and tool execution, the agent loop itself, context assembly, retrieval, memory, workflow state, Skills, permissions, approvals, retries, error handling, handoffs, structured outputs, termination, tracing, rate limits, token budgets, and time budgets. Modern agent SDKs package portions of this runtime — OpenAI’s Agents SDK, for instance, manages agent turns, tools, guardrails, handoffs, and sessions — but the enterprise-specific parts (your permission model, your state machine, your approval routing) are almost always yours to build.

The agent loop, watched closely

At the core sits a loop: understand, plan, act, observe, reflect, continue or finish. Abstractly that is unremarkable. Concretely it is where the agentic behavior comes from. Goal: determine why Promotion P-212 underperformed.

Notice what happened at iteration three. The plan changed because the evidence changed. No fixed workflow written in advance would have known to run a store-group comparison split by price compliance, because that comparison is only meaningful once you discover the compliance problem. That is the entire justification for the loop — and it is also the reason the same task will produce different trajectories on different runs, which has consequences for how you evaluate it.

Termination is an architectural decision

An agent should not reason forever. Without explicit termination logic, autonomy becomes uncontrolled computation — and the bill arrives regardless of whether the conclusion did. Sensible termination conditions include: the objective is achieved, a maximum step count is reached, a token budget is exhausted, a time budget expires, a confidence threshold is met, no useful action remains, user approval is required, or an error requires escalation.

IF   confidence > 0.85
AND  evidence_count >= 3
AND  no critical data gaps
THEN produce conclusion

IF   steps >= 15
THEN stop and escalate for human review
      with findings so far and open questions

Note the second rule’s shape. Escalation should hand over work-in-progress, not an apology. An agent that gives up after fifteen steps and returns “I was unable to complete this task” has spent the budget and produced nothing; one that returns three ruled-out hypotheses and two open questions has done most of an analyst’s morning.

Two further harness responsibilities separate demos from production systems. Budgets should be explicit per run — steps, tokens, wall-clock, and money — and visible in the trace, so cost overruns are a monitored metric rather than a quarterly surprise. And long-running workflows need checkpointing: the ability to persist progress and resume after a crash, a deploy, or a three-day wait for a human approval. A workflow that must be restarted from the beginning because someone approved it on Monday instead of Friday is not a workflow. It is a session.

Once an agent is justified, the next tempting question appears: should we build multiple agents? Again, complexity must be earned. A single capable agent with good tools is usually the right starting point.

Promotion Agent
   |-- sales tool
   |-- pricing tool
   |-- inventory tool
   |-- history tool
   \-- research tool

A single agent with access to sales, pricing, inventory, retailer data, historical promotions, and competitor research may be entirely capable of conducting the whole investigation. The advantages are substantial and easy to undervalue: fewer coordination failures, lower latency, lower cost, simpler observability, simpler debugging, and no duplicated context. Every one of those is a production property, and every one degrades when you split.

When multi-agent architecture earns its cost

Multiple agents become genuinely attractive when:

• Specialists need materially different instructions. A legal review agent and a financial modeling agent operate under different rules and different definitions of “done”.
• Specialists require different tools and permissions. A pricing specialist may reach confidential financial systems a market-research agent must never touch. Separation of duties is easier across process boundaries than inside one prompt.
• Work can genuinely happen in parallel. Several independent investigations run at once and elapsed time actually matters.
• Context domains are very different. Splitting keeps each context focused and small.
• A manager must synthesize independent analyses. Independence is the point: three analyses produced without seeing each other are more informative than one produced three times.

                Promotion Manager
                       |
      +----------------+----------------+
      |                |                |
 Pricing Agent    Supply Agent    Shopper Agent
      |                |                |
      +----------------+----------------+
                       |
                   Synthesis

What does not justify a split: the fact that four different human job titles are involved, or that named agents look impressive on an architecture slide. Coordination is a real tax — extra token spend, extra latency, extra failure surface, and the peculiar failure mode where three agents each assume another one checked the contract.

Agents as tools versus handoffs

There are two fundamentally different ways agents collaborate, and they look deceptively similar on a diagram.

OpenAI’s Agents SDK documentation describes exactly this distinction: a manager pattern in which specialist agents are exposed as tools, versus handoffs in which the specialist takes ownership. Superficially similar. Operationally very different — particularly for audit, because the answer to “who was responsible for this output?” differs in each case.

The orchestration patterns worth knowing

Anthropic includes orchestrator-worker among the commonly useful agentic architectures, and it is the pattern that most often earns its keep in enterprise settings — precisely because real cases vary in ways you cannot pre-enumerate.

Orchestration should reflect business control

Agent orchestration should not merely follow technical convenience. It should encode business responsibility. The questions are organizational: who owns the final decision? Which steps can run independently? Which specialist has authority? When does control return to a manager? Which operations require approval? Which system holds authoritative state?

Answer those and you are doing digital organizational design. Which raises an obvious temptation — and a trap. If the company has a sales analyst, a revenue analyst, a trade marketing analyst, and a category analyst, it does not follow that the system needs four agents. Human organizational structure exists partly because humans have limited attention, limited memory, limited hours, specialist training, and communication boundaries. AI systems have different constraints and different economics. One agent with the right tools and Skills may dissolve several boundaries that only ever existed because a person cannot read forty thousand promotions before lunch. Architecture should reflect computational logic, not the org chart.

Every agentic system should have an explicit autonomy model. Do not leave autonomy implicit — implicit autonomy always turns out to be broader than anyone intended. Four action classes are usually enough:

• Automatic. The agent may execute without approval: read data, calculate metrics, search documents, create an internal draft.
• Automatic with guardrails. The agent may act if conditions pass: annotate a record, adjust a recommendation within a stated band, send an internal notification below a threshold.
• Approval required. A named human must authorize: send an external contract, change customer pricing, commit promotional investment, override a forecast beyond a threshold.
• Forbidden. The agent cannot perform the action at all: delete financial records, disclose customer secrets, move money outside policy, alter a compliance control.

The third column is the one that matters. Notice that “forbidden” is not implemented as an instruction — it is implemented as the absence of a tool.

A sentence in a prompt asking the model not to do dangerous things is a weaker control than an architecture in which the dangerous thing cannot be done.

Guardrails

Guardrails enforce boundaries around the system, and they can inspect user input, model output, tool input, tool output, and actions. A guardrail might verify that the promotion ID exists, that a proposed discount does not exceed the approved limit, that customer personal data is absent from the output, that a tool request conforms to its schema, or that the requesting user holds the authority for the action being taken. OpenAI’s Agents SDK distinguishes agent-level input and output guardrails from tool guardrails that run around custom tool execution — a useful separation, because the two catch different classes of problem.

The architectural point is that safety-sensitive boundaries belong in deterministic controls wherever possible. Prompts express intent. Permissions express power.

Least privilege, identity, and the injection problem

Agents should receive the minimum permissions needed for the task. If an inventory agent needs read access to inventory data, it should not also carry payroll access, CRM deletion rights, payment permissions, or production infrastructure credentials. This matters more for agents than for ordinary software because an agent’s tool access is its operational power, and because the thing deciding which tool to call is probabilistic.

Three controls deserve explicit design rather than inheritance from whatever the platform defaults to:

1. 01Identity and delegation. Under whose authority does the agent act? A service account with union-of-everyone permissions is the single most common enterprise agent security defect. Prefer acting on behalf of the requesting user, with that user’s scope, so an agent can never become a privilege-escalation path.
2. 02Separation of duties. Recommendation, approval, and execution should not collapse into one identity. If the same agent can propose a spend change and execute it, the approval step is decoration.
3. 03Untrusted content is data, not instruction. Retailer emails, PDFs, web pages, retrieved documents, and tool responses all enter the context. Any of them can contain text shaped like a command. The harness must label provenance, and the permission model must assume the model will sometimes be persuaded — which is precisely why consequential actions sit behind deterministic gates rather than behind the model’s judgment.

Human oversight has levels, not a switch

Agent
  Proposed: increase retailer discount 20% -> 28%
  Evidence:  compliance 61%; compliant stores +16.7% uplift
  Effect:    +€310k spend, +€180k incremental contribution
  Risk:      margin below guardrail if volume lands under 92% of plan
  Reversible: yes, until the retailer is notified

System
  Action exceeds autonomous threshold (€250k)
  Approval requested from: Commercial Director

Compare that with a dialog that says “Approve?”. Approval without evidence, effect, alternatives, and reversibility is not oversight — it is a click that transfers blame. If reviewers approve everything within seconds, you have not installed a control; you have installed a formality, and your evaluation data will not tell you the difference.

Many teams build an agent and ask afterwards whether it works. A stronger approach defines success much earlier — eval-driven development. Before implementing the full system, write down what good performance looks like. Anthropic recommends starting evaluation work early precisely because it forces teams to make success criteria explicit, and that argument is even stronger inside an enterprise, where four functions will otherwise discover at launch that they meant four different things.

Now the architecture has a target — and, just as importantly, the disagreements surface while they are still cheap.

What an agent evaluation actually contains

An agent evaluation is more elaborate than checking a single model answer. Anthropic’s agent evaluation guidance names the components: a task defines the problem and criteria; an environment supplies the systems and data; the agent and its tools do the work; a trial is one attempt; the trace or trajectory records what occurred; graders score it; and the outcome is the final state of the environment.

Why agent evals are hard

Traditional software gives input A to a deterministic function and gets output B. An agent may reach the same correct conclusion by different routes:

Trial 1   pricing -> availability -> historical promos -> conclusion
Trial 2   availability -> competitor research -> pricing
                       -> historical comparison -> conclusion

Both may be entirely acceptable. So evaluation has to judge the final outcome, the constraints that had to hold, the evidence offered, the tool behavior, the reliability across repeated runs, and — selectively — the quality of the trajectory. Avoid requiring one exact reasoning path unless the process itself is the regulated thing. And because agents are stochastic, a single passing run proves very little: run each task several times and look at the distribution. The gap between “passed at least once” and “passed every time” is exactly the gap between a demo and a production system.

Grade the outcome, not the eloquence

Imagine a travel agent that says “your flight has been booked.” A language evaluator might score that response highly: fluent, confident, complete. The only question that matters is whether a valid booking exists in the reservation system. Similarly, when an FMCG agent claims “I updated the promotional plan,” the grader should check the promotion database. Anthropic explicitly distinguishes the transcript from the final environment outcome for this reason, and outcome graders are very often the strongest signal you can build.

Two suites, two purposes

Capability evals ask how good the system can become. They contain hard tasks, you expect failures, and they guide improvement. Regression evals ask whether the latest change broke something that used to work. They contain established capabilities, you expect high pass rates, and they run on every change to a prompt, Skill, tool schema, model version, or threshold. Keeping them separate matters: mixing them produces a single number that is neither an improvement target nor a release gate.

There is also a distinction worth stating plainly, because the two words are one letter apart in conversation. The agent harness runs the agent. The eval harness tests the agent — running tasks, capturing execution, grading outputs, and aggregating results.

                    EVAL HARNESS
                         |
      +------------------+------------------+
      v                  v                  v
    Task 1             Task 2             Task 3
      |                  |                  |
      v                  v                  v
  Agent harness      Agent harness      Agent harness
      |                  |                  |
      v                  v                  v
    Trace              Trace              Trace
      |                  |                  |
      +------------------+------------------+
                         v
                      Graders
                         v
                    Eval report

Evaluation and observability answer different questions

These are also routinely conflated. Evaluation asks how good the system is. Observability asks what happened inside this particular run. You need both, and neither substitutes for the other. An evaluation tells you the pass rate fell from 92% to 81%. Observability tells you the pricing tool returned timeouts in 37% of the failed cases. Without the first you do not know there is a problem. Without the second you cannot fix it.

When an agent runs, capture a trace containing at least:

run_id            tool calls + arguments
user request      tool results + latencies
agent + model     handoffs
prompt version    guardrail events
Skill versions    retries and fallbacks
context inputs    tokens, cost, duration
                  final output + environment outcome

OpenAI’s Agents SDK tracing records model generations, tool calls, handoffs, guardrails, and custom events during a run for exactly this purpose. To see why it is indispensable, imagine the report you will actually receive: “the agent recommended increasing inventory by 40%, and that was wrong.” The candidate causes include bad source data, the wrong tool, a tool timeout, a stale inventory snapshot, the wrong Skill, too much context, missing context, a model reasoning error, an incorrect business rule, contaminated memory, a prompt regression, and a changed model version. With only the final sentence you cannot distinguish them. With the trace you reconstruct the run in minutes.

The production metrics layer

The last category is the one that matters. A 95% eval score is not a business outcome, and the honest cost metric is cost per successful outcome— including retries, failed runs, and the human review time the system still consumes. Two hours “saved” that reappear as review and rework were not saved.

Once the system works locally, deployment should be progressive. Each stage buys a different piece of evidence, and skipping stages does not save time — it defers the discovery of the same problems to the most expensive possible moment.

• Local. Prompt iteration, tool testing, simple evals, debugging. Necessary, but local success proves very little about production reliability.
• Sandbox. The agent operates in an isolated environment where tool use, permissions, file operations, and error handling can be exercised without touching real systems.
• Integration testing. Real dependencies or realistic replicas: database schemas, authentication, API contracts, MCP connections, timeout behavior, data formats. A large share of “AI failures” are integration failures wearing a costume.
• Staging. A production-like environment testing deployment, logging, permissions, data pipelines, full workflows, and observability. Environmental realism without production consequences.
• Shadow mode. The agent receives real tasks but controls nothing.
• Human-in-the-loop pilot. Real work, with approval required for meaningful actions.
• Canary. A small share of live volume, expanded as quality holds.
• Production. With everything above still running underneath it.

Many “AI failures” are integration failures, and most of the rest are adoption failures. Only a minority are genuinely reasoning failures — which is worth remembering when a pilot disappoints and the instinct is to change the model.

Shadow mode is the most underused technique in enterprise AI

In shadow mode, a human analyst investigates Promotion P-212. At the same time, the agent independently investigates Promotion P-212. Then you compare the conclusions. Over a few hundred cases you can measure agreement rate, the character of disagreements, false positives, missed issues, speed, and quality — and you can do it before granting the agent any authority at all.

This produces something no demo can: evidence. It also produces something no eval suite can produce on its own — the cases where the agent and your best analyst disagree, which are the most valuable evaluation data your organization will ever generate. Where the human was right, you have a new regression test. Where the agent was right, you have a business case.

The human-in-the-loop pilot that follows works the same way in reverse: collect the reasons for every rejection or edit. A rejected recommendation is a labeled failure case delivered for free by someone who understands the domain.

Canary and progressive autonomy are two different dials

Canary deployment scales traffic: 5% of promotions, then 20%, 50%, 80%, 100%, as quality holds. Progressive autonomy scales authority, which is a separate decision and often moves more slowly.

Expressed as levels: at level 0 the agent recommends and a human executes. At level 1 the agent drafts and a human approves. At level 2 the agent executes low-risk actions and humans approve high-risk ones. At level 3 the agent executes most actions and humans monitor exceptions. At level 4 the agent operates autonomously within policy — which still means scope, budgets, stopping conditions, and a human able to stop it. For most enterprises this ladder is a far better path than attempting full autonomy at launch, because each rung is purchased with evidence rather than granted by enthusiasm.

Production becomes a learning system

Once deployed, the architecture enters a loop that never really stops:

Production
   -> observe failures
   -> add the failure case to the eval suite
   -> improve prompt / Skill / tool / architecture
   -> run the regression suite
   -> deploy
   -> observe again

This is one of the most important operational concepts in agent development. Over time the evaluation suite becomes a record of everything the organization has learned not to break. Two disciplines keep it honest: treat every change to a model, prompt, tool, Skill, or threshold as a versioned release that must pass the regression suite; and build the recovery controls — a kill switch, a rollback path, a way to quarantine a misbehaving agent — before you need them rather than during the incident.

The repository is part of the agentic operating system

A production agentic workflow should live in version control, in one place, with everything that determines its behavior:

promotion-agent/
|
|-- agents/           orchestrator, pricing, supply
|-- skills/           promotion-analysis, retailer-analysis
|-- tools/            sales.py, inventory.py, pricing.py
|-- prompts/
|-- policies/         permissions.yaml, approvals.yaml
|-- orchestration/
|-- evals/            capability + regression suites
|-- tests/
|-- infrastructure/
\-- README.md

This gives the system a history. When behavior changes you can ask which prompt changed, which Skill changed, which tool schema changed, which model version changed, which policy changed, and which eval caught it. Without version control across all of these, agent improvement degenerates into guesswork — and the fact that the model is stochastic will be blamed for changes that were entirely deterministic.

Agentic systems consume substantially more computation than simple model calls, because one user task can expand into ten model calls, twenty tool calls, three retrieval operations, two specialist agents, and an evaluator pass. That is not waste — it is what buys the adaptability — but it must be designed rather than discovered.

Cost engineering

Track tokens per successful task, model mix, tool cost, retry cost, failed-run cost, context size, and agent steps. The most effective single lever is model routing: use a stronger model for difficult planning and cheaper models for classification, extraction, formatting, and routine evaluation — and use no model at all where a function will do.

Latency engineering

An agent can be excellent and still fail commercially. If a human analyst takes twenty minutes and the agent takes twenty-seven, the agent has not produced a compelling proposition — even at higher quality — because the workflow around it was built for a twenty-minute answer. Latency accumulates through reasoning steps, tool calls, sequential agents, retrieval, retries, and generation. The remedies are parallelization, better tools that return the right shape in one call, smaller contexts, fewer loop iterations, model routing, and moving computation into deterministic code. Optimize outcome, cost, and speed together; any two of the three is a prototype.

Reliability engineering

Agents interact with unreliable infrastructure. APIs fail. Databases time out. MCP servers go away. Documents are malformed. Permissions expire. Data is missing. The harness therefore needs retries, fallback strategies, timeout handling, circuit breakers, validation, and graceful escalation.

call retailer API
   -> timeout
   -> retry (1 of 1)
   -> timeout
   -> fall back to cached warehouse data
   -> attach freshness warning: "data as of 06:00, 2 days stale"
   -> continue, and surface the caveat in the conclusion

The agent may reason dynamically, but reliability is engineered deliberately. Note the last two lines: a fallback that silently substitutes stale data is worse than a failure, because it produces a confident answer built on a fact nobody knows is old.

Explainability and evidence-sensitive confidence

In business workflows the recommendation alone is rarely sufficient. Users need to know which data was used, which tools were called, which evidence supported the conclusion, which assumptions were made, and what uncertainty remains. Compare:

Confidence deserves the same treatment. Agents express confidence linguistically, and linguistic confidence is close to meaningless. A better system computes it from data completeness, the number of corroborating sources, the consistency of evidence, the strength of the causal relationship, and any unresolved contradictions:

Confidence: 82%

  supporting
    + price compliance anomaly (large, measured)
    + store-level uplift correlation (412 stores)
    + availability normal (rules out the obvious alternative)
    + no major competitor event in the window

  remaining uncertainty
    - media exposure data incomplete for weeks 3-4

Now a commercial manager can decide how much weight to place on the recommendation — which is the actual job of a decision-support system.

Assemble everything and a production agentic workflow looks like this — considerably less glamorous, and considerably more useful, than a collection of autonomous agents.

The orchestration layer answers “who does what next?” Sometimes deterministically (validate, analyze, publish). Sometimes conditionally (low risk auto-approves; high risk routes to a human). Sometimes the model chooses (“I need inventory data next”). It is the control plane for the workflow, and it is where business responsibility is encoded.

The capability layer answers “what can the system actually do?” Retrieve sales, query inventory, calculate ROI, browse information, send messages, update records, generate files. Without useful capabilities, autonomy is purely verbal.

The enterprise systems layer is where the value actually lives: ERP, CRM, POS, planning, the data warehouse, email, documents, retailer portals, internal applications. An agent that cannot interact with the organization’s systems remains a conversational interface. Agentic transformation becomes meaningful only when intelligence connects to operational systems.

And seven concerns cut across all of it: context engineering (what should the model see now?), memory (what should persist?), state (what is currently true?), the harness (how does the model operate?), governance (what may it do?), evaluations (how good is it?), and observability (what happened?). These layers, more than the model choice, determine whether a system moves from demo to production.

The steps above form a lifecycle, and a lifecycle is only real if it leaves evidence behind. The test of whether a workflow was designed rather than improvised is simple: do the artifacts exist? If the answer is no, the system may still work — but nobody will be able to say why, change it safely, or defend it when it is questioned.

Notice how few of the seventeen stages are about the model. Two, at most. That ratio is not an accident of presentation — it is roughly the ratio of effort in a project that reaches production.

The method is only convincing when it survives contact with a second and third process. Here are three, each allocated across the four mechanisms.

Demand forecast exception management

A poor design says “let the AI agent forecast demand.” But most demand forecasting systems already produce forecasts mathematically, and statistical or machine-learning models generally beat a language model at extrapolating a time series. The agent should own the exception investigation instead — the part that today consumes a demand planner’s week and is performed inconsistently.

Forecasting engine
   -> exception detection
   -> agent investigation
   -> recommended adjustment + evidence
   -> human approval if material
   -> planning system

Category management: preparing a retailer review

A category manager preparing a retailer review needs deterministic calculation of category growth, share, distribution, and velocity; an LLM workflow to summarize trends, extract themes, and format the deck; an agent to determine which trends actually matter, investigate anomalies, identify opportunities, and compare competitors; and a human to make the strategic commitment to the retailer. The manager gets a far more capable system precisely because the architecture combines four forms of intelligence rather than asking one of them to do everything.

Sales opportunity identification

A distributor with thousands of retailers wants to find accounts where assortment expansion would create value. Deterministic systems calculate current assortment, sales per SKU, distribution gaps, category performance, and account size. A model interprets qualitative retailer notes and salesperson comments — the unstructured half of the picture that no dashboard has ever contained. An agent investigates which accounts have the strongest expansion opportunity and why, combining transaction data, geography, store type, history, assortment, and that qualitative signal, then drafts recommended actions. The salesperson remains responsible for the customer relationship, which is not a limitation of the technology but a correct allocation of accountability.

The phrase “AI employee” encourages architecture that cannot be evaluated. Compare two scopes:

Narrowness improves reliability. That said, broad agents can make sense when the surrounding harness provides strong control. A commercial operations agent might hold many Skills — promotion-analysis, pricing-analysis, retailer-review, sales-forecasting, category-analysis — loading whichever the task requires, while its capabilities remain carefully permissioned. That resembles a capable employee with access to many internal playbooks and a limited set of keys. The breadth lives in the know-how layer; the boundaries live in the permission layer. Reverse those two and you have built something nobody can govern.

1. 01Starting with “we need an agent.” Start with the workflow. An agent is one architectural option among six.
2. 02Making everything probabilistic. Use deterministic systems wherever the operation should be deterministic. Arithmetic is not a reasoning task.
3. 03Giving one agent dozens of poorly designed tools. Tool quantity is not capability quality. Fewer, sharper contracts beat a wide surface the model has to guess at.
4. 04Storing authoritative workflow state in conversation memory. Use a database and a state machine. “The agent remembers” is not a control.
5. 05Loading everything into context. Context is scarce attention, not free storage. Use retrieval and progressive disclosure.
6. 06Creating multiple agents too early. Start with one. Split when specialization, permissions, or parallelism create measurable value.
7. 07Treating Skills as tools. Skill is know-how; tool is capability. Confusing them produces agents that can act but do not know how your company works.
8. 08Building evals only after deployment. By then nobody agrees what correct behavior was supposed to be.
9. 09Confusing observability with evaluation. Trace the system and evaluate it. One tells you there is a problem; the other tells you what it is.
10. 10Deploying straight from local development. Sandbox, integration, staging, shadow, pilot, canary. Each stage buys evidence you cannot get any other way.
11. 11Putting security only in the system prompt. Enforce permissions in architecture and tools. A prompt is not a permission system.
12. 12Measuring only AI metrics. A 95% eval score is not revenue, margin, speed, working capital, productivity, or decision quality. Tie the agent to a business metric or expect to defend it annually.

Before building an agentic workflow, you should have answers to each of these. If you do not, the architecture is not ready for production — and no amount of model capability will substitute.

Agentic AI invites us to rethink what software is for. Traditional software says: we know the process — encode it. Agentic systems add: we know the objective, but parts of the path must be discovered. That is the architectural frontier, and it suggests distinguishing two kinds of complexity.

Traditional automation is powerful when the shape is if X then Y. Agents become valuable when the shape is: we want outcome Y; examine the situation, determine which actions are appropriate, use the available capabilities, adapt when conditions change, and escalate when necessary. That is a shift from software that executes instructions to software that pursues bounded objectives, and it is why agentic systems are an architectural development rather than a feature.

Model choice is only one layer

Teams often spend disproportionate energy on which model to use. That choice matters. It is also one term in a longer product:

Model + Prompt + Context + Skills + Tools + Data
      + Orchestration + Memory + Harness + Evals + Governance

A stronger model with poor tools frequently performs worse than a slightly weaker model with excellent ones. A very large context window filled with badly selected context performs worse than a smaller, carefully engineered one. The system is the product.

The future enterprise contains both workflows and agents

It is unlikely that enterprises become collections of autonomous agents while conventional software disappears. The plausible architecture is hybrid: deterministic systems, rules, machine learning, LLM workflows, agents, and humans — each doing what it is good at. ERP systems remain good at transactions. Databases remain good at holding state. Python remains good at calculation. Models are good at language and interpretation. Agents are good at navigating uncertain multistep work. Humans remain essential where accountability, relationships, judgment, and meaning matter. The future enterprise is an orchestration problem across all of them.

This is why FMCG is such fertile ground. Demand forecasting, promotion planning and evaluation, pricing, revenue growth management, assortment, category management, inventory optimization, route-to-market, distributor management, sales planning, field sales, merchandising, customer service, procurement, marketing analytics, and reporting all share the same structure: deterministic calculation + fragmented enterprise data + repeatable methodology + contextual reasoning + human decisions. That is exactly the shape agentic architecture is built for.

The pattern repeats: the deterministic engine stays, the reporting layer stays, and the agent takes the exception, the investigation, and the explanation — the part that is currently done inconsistently because it depends on who has time.

From insight systems to action systems

For decades, enterprise software has followed one pattern: data becomes a dashboard, a human interprets it, a human decides, a human acts. A promotion agent that stops at “here is what happened” is just a dashboard with better prose. The shift is to a system that participates in the workflow itself.

yesterday   data -> dashboard -> human interprets
                 -> human decides -> human acts

today       data -> system detects -> agent investigates
                 -> agent recommends -> policy determines autonomy
                 -> agent or human acts -> result measured
                 -> system learns

Traditional analytics tells you what happened. A good agentic system continues: why did it happen, what should we investigate next, what should we do, shall I prepare the action, shall I execute the approved parts. That is a different relationship between intelligence and work — and it changes the human role rather than removing it. The commercial leader spends less time asking where the spreadsheet is and more time asking what strategic choice to make.

Agentic architecture is organizational architecture

There is a deeper observation underneath all of this. When you design agents, Skills, permissions, handoffs, approvals, tools, and responsibilities, you are designing an organization. Consider what defines a role in a human company — a commercial director, a category manager, an analyst. Each has responsibilities, tools, information access, permissions, expertise, and escalation paths. Agent architectures have precisely analogous structures, which is why the design conversations feel unexpectedly familiar to experienced operators and unexpectedly foreign to engineers.

This is why agent design increasingly overlaps with operating-model design — and also why the trap described earlier is so easy to fall into. The analogy is structural, not literal. Copying the org chart into an agent topology reproduces boundaries that exist because of human limits, not because the work requires them.

What happens to the human role

Agentic systems can automate substantial parts of knowledge work, and the honest version of that sentence is uncomfortable enough to be worth stating plainly: a large share of what a commercial analyst does today is retrieval, reconciliation, and formatting, and those parts genuinely move. What is left is not less valuable. It is more concentrated.

Two failure modes deserve naming. The first is automation complacency: when the system is usually right, reviewers stop reviewing, and the rare wrong answer passes untouched. The countermeasure is design, not exhortation — show uncertainty and missing evidence, sample-audit deliberately, and reward catching agent errors. The second is expertise erosion: if no one ever performs the analysis manually, in three years no one will be able to tell whether the agent is wrong. Rotation, periodic manual review, and training cases built from real disagreements are cheap insurance against an expensive loss.

In the promotion example, the agent performs a large amount of investigative work and the commercial leader spends more time asking what strategic choice to make. That is the deeper opportunity — provided someone deliberately keeps the capacity to disagree with the machine.

At TiMiNa we approach agentic architecture through a single principle, and it is deliberately symmetrical. We should not ask a model to perform arithmetic that software can calculate exactly. We should not force a deterministic workflow to resolve ambiguity it cannot understand. We should not give an agent authority it does not need. We should not keep humans performing repetitive investigative work that machines can handle reliably. And we should not remove humans from decisions where accountability, judgment, and relationships remain essential.

Good agentic architecture is not about maximizing autonomy. It is about designing autonomy precisely.

Which makes the unit of transformation neither the chatbot nor the agent, but the workflow. Start with an economically meaningful one. Understand it. Decompose it. Rebuild it with the appropriate combination of deterministic software, intelligence, autonomy, and human accountability. Then measure the outcome. That is agentic transformation; everything else is tooling.

The mental model, in fifteen steps

 1  Understand the work.
 2  Break it into tasks.
 3  Identify where the uncertainty actually is.
 4  Assign the right kind of intelligence to each part.
 5  Map the required capabilities.
 6  Connect systems through well-designed tools.
 7  Encode reusable know-how as Skills.
 8  Design the orchestration.
 9  Separate context, memory, and state.
10  Build the harness.
11  Define autonomy and permissions per action.
12  Create the evaluations before the system.
13  Instrument everything.
14  Deploy progressively.
15  Learn from production — then repeat.

What is the difference between an agentic workflow and an AI agent?

An agent is one actor that dynamically chooses its actions. An agentic workflow is the complete process connecting agents, humans, deterministic software, tools, state, policies, approvals, and outcomes. Most production value comes from the workflow, not the agent.

How do I know whether a task needs an agent at all?

Look for several signals together: the path cannot be known in advance, multiple tools may be needed, intermediate results change the plan, the information is ambiguous, failure recovery matters, and the environment provides feedback. If the path is stable, build a workflow. If the operation is exact, write code.

What is the difference between a tool and a Skill?

A tool is a capability the agent can invoke — it gives the model hands. A Skill is reusable procedural knowledge that tells the agent how your organization performs a kind of work. Tools without Skills produce agents that can act but do not know your methodology. Skills without tools produce agents that know what to do and cannot do it.

Where does MCP fit in an enterprise architecture?

In the connectivity layer. It standardizes how AI applications reach external capabilities and context, which makes a large share of the integration layer reusable across agent platforms. It does not replace APIs or business systems, and it does not supply governance — identity, least privilege, versioning, and monitoring still have to be designed.

What is the difference between context, memory, and state?

Context is what the model can see right now. Memory is information persisted so it can be retrieved later. State is the authoritative current condition of the workflow. Keeping approvals, order identifiers, and stage transitions in state rather than in conversation is what prevents duplicate and contradictory actions.

What is an agent harness?

The runtime surrounding the model that makes agentic execution possible: context assembly, tool registry and execution, the loop, state, memory, permissions, approvals, retries, termination, budgets, and tracing. The model supplies intelligence; the harness makes it operational.

How should agent evaluations be designed?

Before the system, not after. Define tasks with explicit pass and automatic-fail criteria, grade the final environment outcome rather than the transcript, combine deterministic, model-based, and human graders, run each task multiple times because agents are stochastic, and keep capability evals separate from the regression suite that gates every release.

How is observability different from evaluation?

Evaluation answers “how good is the system?” Observability answers “what happened inside this run?” The first detects that quality moved. The second explains why. You need both, and traces are what make agent debugging possible at all.

How much autonomy should an agent have initially?

Less than you want, and per action rather than per agent. Read and calculate automatically; recommend freely; require approval for consequential, external, or irreversible actions; and make dangerous actions architecturally impossible. Then expand as shadow-mode and pilot evidence accumulates.

Why do agent pilots fail to reach production?

Rarely because the model was insufficiently capable. Usually because the workflow was never mapped, exceptions dominated, data was present but not operationally usable, decision rights were unclear, evaluations were added late, cost per successful task was never measured, or nobody owned the system after launch.

The model attracts most of the attention. Production value comes from the system around it. A reliable agentic workflow requires decisions about workflow design, deterministic logic, model reasoning, capabilities, tool interfaces, integrations, Skills, context, memory, state, orchestration, agent collaboration, harnesses, permissions, guardrails, human approvals, evaluations, observability, deployment, and continuous improvement.

That is considerably more complicated than “build an AI agent.” It is also why the next generation of enterprise AI will be driven by agentic system design rather than by access to more capable models. The companies that become genuinely agentic will be the ones that learn where autonomy belongs, how to surround models with reliable infrastructure, how to encode organizational know-how, how to connect intelligence to real business systems, and how to measure machine work with the same seriousness they apply to human and software processes today.

The goal is not to replace every workflow with an agent. The goal is to redesign work so that every step is performed by the mechanism best suited to it. Sometimes that will be software. Sometimes a single model call. Sometimes a Skill-guided agent. Sometimes a coordinated group of agents. And sometimes it should remain a human.

That combination is where agentic AI stops being a demo and becomes an operating model.