The hard part of agentic AI is not the model. Frontier models are already capable enough for most enterprise workflows. What separates a real agent from a wished-for one is the set of implementation decisions you make around the model — what it can perceive, what it is allowed to do, where a human stays in the loop, who manages it, and how you hold it to standard once it is live.

I think the most useful reframing is this: an agent is not a smarter chatbot. It is a unit of work that can be delegated, monitored, and governed. That shift moves your people from task executors to managers of autonomous systems — and it means the questions that matter are operational and organizational, not just technical. Here is the playbook I’d use to take an enterprise agent from design to first production slice.

1. Design the agent: five building blocks

Before writing a line of orchestration code, work through five questions in sequence. Each one is a commitment, and naming the open questions is itself a useful output.

  • Perception — how will the agent observe the world? Define the inputs, formats, and sources: API-driven data from your systems of record, telemetry from monitoring tools, documents, tickets. The unglamorous problem here is usually normalization — reconciling inconsistent identifiers across systems without introducing correlation errors.
  • Action — what is the agent allowed to do? Enumerate the specific tools and APIs it can invoke and the side effects of each. A safe default for a first deployment is a recommendation and orchestration role — the agent enriches, prioritizes, drafts, and opens tickets, while consequential changes to production systems stay human-controlled.
  • Planning — how will it reason about multi-step tasks? A decomposed, multi-agent workflow (specialized sub-agents coordinated by an orchestration layer) tends to beat one monolithic agent. It improves auditability and limits the blast radius of any single reasoning failure.
  • Memory — what must it remember? Distinguish short-term working memory for an active task from persistent memory across sessions: history, prior decisions, human feedback. Persistence is what stops an agent from re-escalating the same known-benign condition forever. Decide your retention policy for sensitive data up front.
  • Safety — how is risk architected into the system, not the model? This is the one that matters most. You do not rely on the language model to manage its own risk. Confidence scoring, hard-coded policy constraints, role-based access, approval thresholds, and audit logging all live outside the model. The surrounding system decides what is permissible regardless of what the model outputs.

The discipline of the Safety row is to find the riskiest place you’re still trusting the model to make a judgment it shouldn’t — for example, letting the model infer business impact from technical signals alone, when business criticality should come from validated metadata and external policy logic. Move that decision outside the model and it becomes consistent and defensible instead of nondeterministic.

2. Build, buy, or stack

At each layer of the stack — model, framework, platform — you choose to build, buy, or combine. The decision is driven by the autonomy you need and the skill set you have, not by technology preference. In practice, the answer is almost always stack:

  • Model: Buy the frontier model for reasoning and language; building a foundation model in-house is rarely justified. Where it pays off is smaller, internally controlled models for domain-specific enrichment or sensitive workflows you don’t want leaving your environment.
  • Framework: Buy or adopt open-source orchestration to avoid rebuilding commodity plumbing — but build the governance, escalation, and workflow logic yourself. That layer defines your decision thresholds and approval chains; it is exactly what you should own for auditability.
  • Platform: Buy enterprise infrastructure for scalability, monitoring, and operational maturity, then orchestrate it on top of the systems you already run. The value comes from connecting existing systems intelligently, not replacing them.

The layer most likely to expose a skill-set gap is rarely the model — it’s the integration work that crosses historically siloed teams. Closing that gap is as much an organizational-alignment problem as a technical one.

3. Draw the threshold map

The single most important design artifact is the human-in-the-loop threshold map. For each decision type the agent will encounter, define three lines:

  1. The agent acts autonomously when confidence is high and the stakes are low — e.g., enrichment and classification on low-criticality items.
  2. The agent escalates when confidence drops, data conflicts, or ownership is unclear.
  3. A human originates the decision when the action touches regulated, safety-critical, or high-disruption systems.

The honest move is to name the threshold you’re least sure about — the line you genuinely don’t know yet — and design an experiment to find it. A controlled pilot comparing agent recommendations against senior-expert decisions over several cycles will calibrate where autonomy is safe and where human judgment remains essential. You discover thresholds; you don’t guess them.

4. Ship a three-week MVP

Pick the smallest end-to-end slice of the workflow that an agent could plausibly handle, and hold the scope ruthlessly tight. Three weeks is honest only if the scope is. Describe the MVP the way you’d describe it to the engineer building it — explicit start and end points — and run it in recommendation-only mode, no autonomous action on production systems.

Then name the five (or fewer) people who’ll use it first and what feedback each gives: the operator who judges output quality, the engineer who judges integration friction, the risk/governance lead who judges auditability, the manager who judges adoption, the director who judges strategic fit.

The hardest part is what you leave out. Defer the high-risk capabilities — autonomous execution, anything requiring mature rollback — and write down the trigger condition that brings each one back into scope (for example: “only after the agent demonstrates consistent accuracy and stable human trust over multiple evaluation cycles”). Deferral with a trigger is a plan; deferral without one is avoidance.

5. Every agent needs a manager

An agent needs a day-to-day manager, and it should not be the engineering team. The right person is a senior operational lead who understands the domain, carries cross-functional credibility, and can judge whether the agent is producing operationally meaningful outcomes — not just technically correct ones.

This role has responsibilities that are genuinely new, not adapted versions of existing ones:

  • Continuous decision calibration — tuning escalation thresholds, prioritization logic, and confidence scoring against real outcomes. You’re supervising autonomous decision behavior, not human task execution.
  • Agent performance governance — reviewing reasoning quality, watching for drift, validating output consistency, and catching where recommendations diverge from expected behavior.
  • Cross-system risk coordination — actively managing the data quality and contextual ecosystem the agent depends on across every system it touches.

Start this as an extension of a senior role, with workload deliberately reduced to create capacity for oversight. As agents spread across workflows, expect to formalize a dedicated AgentOps or AI-operations leadership function to manage autonomous systems at portfolio scale.

6. AgentOps: the measurement discipline

The MLOps inheritance — continuous integration, delivery, training, monitoring — isn’t enough. Agents demand continuous evaluation as a first-class deployment concern, with skew detection built into the architecture. The dashboard isn’t a monthly report; it’s a continuous conversation with your own system.

  • Track in real time: at least two production metrics that capture the work the agent actually does — decision/recommendation accuracy against validated human decisions, and the cycle-time improvement the agent delivers.
  • Review periodically with humans: the qualities a metric can’t capture — whether the agent appropriately weighs context, business impact, and edge cases. A structured human audit on a regular cadence catches what dashboards miss.
  • Detect drift early: agent behavior drifts as input distributions shift, models are upgraded, or tool APIs change shape. The early-warning signal is rising disagreement between human decisions and agent recommendations, or abnormal patterns and climbing false-escalation rates. Compare historical to current outcomes continuously.
  • Assign ownership and authority: name who reviews the dashboard, on what cadence, and — critically — who has the authority to pause autonomous action and tighten thresholds as risk rises. That authority should sit with operational leadership, not engineering alone.

The through-line

Put these together and the strategy writes itself: build the capability as a stack, deploy an agent whose safety lives in the surrounding system, keep humans in the loop at the consequential decisions, give it a real manager, and hold it to standard with continuous evaluation. Start in recommendation mode and earn autonomy incrementally as trust and accuracy compound.

The goal isn’t to do today’s work faster. It’s to build an operating model where autonomous systems are designed, managed, and governed as a normal part of how the enterprise runs — ambitious in where you point it, disciplined in how you control it.

This is the second of a three-part series on enterprise agentic AI:

  1. Choosing Where to Start — the strategy
  2. A Builder’s Playbook — the implementation (this article)
  3. Scaling Responsibly — the governance