Part 1 — The Agentic Enterprise is here: Navigating the AI tool explosion
Most enterprise AI conversations still start in the wrong place: model selection. The real question is bigger: how do we turn AI into secure, reliable, and repeatable work inside real systems, with predictable economics? That’s the shift from “answers” to “outcomes,” and it’s why agents are suddenly everywhere.
As agents spread, the ecosystem has not merely grown—it has reorganized. Frontier models can sustain longer, more complex work, while model labs and cloud providers now package context management, sessions, sandboxes, tool execution, memory, subagents, tracing, evaluation, identity, and policy as managed agent runtimes. “Harness engineering” has moved from an implementation detail to a product category. The result is less need to assemble every runtime primitive yourself, but a more important architecture question: which parts should you buy, which should remain enterprise-owned, and where do you preserve control and portability?
This post maps the landscape and offers a practical rubric for choosing the right architecture and tools for your specific workflow without chasing hype or creating lock-in. In Part 2, we’ll look at why PoCs stall and what “enterprise-grade” actually means in architecture terms.
Executive summary (for leaders who skim)
Executive summary (for leaders who skim)
Agentic AI has moved from short tool-calling loops toward long-running work: stronger frontier models can plan, use tools, recover, preserve state, and coordinate subagents across hours or days.
The market is converging on managed agent/harness platforms. Context, sandboxing, sessions, memory, tool gateways, observability, evaluation, and identity are increasingly platform capabilities rather than bespoke plumbing.
That convergence does not eliminate enterprise rails. Once agents act on systems of record, the durable control plane is identity, authorization, policy, data boundaries, auditability, evaluation, observability, cost controls, and containment.
Pick from the use case backwards, then make an explicit buy/build decision: buy commodity runtime primitives where they fit; own the workflow semantics, enterprise integration contracts, policy, evals, and evidence that differentiate your business.
1) The shift: From answers to outcomes
The first wave of GenAI in enterprises delivered copilots: summarization, drafting, and chat-based Q&A. Agentic AI changes the center of gravity from producing an answer to completing work. Today’s frontier systems can sustain longer horizons, use tools and files, execute code in controlled environments, preserve intermediate state, and coordinate parallel subagents. OpenAI’s September Agents API, for example, exposes the managed Codex harness for long-running cloud agents; Anthropic’s Managed Agents similarly separates a hosted harness from the model; and Google and Microsoft are converging on managed agent platforms rather than model endpoints alone. The architectural consequence is the same as before, but stronger: as autonomy rises, non-functional requirements become part of the product—not an afterthought.
A useful way to anchor the conversation is the “answers → actions → outcomes” ladder (Figure 1). Assist-only use cases can still move quickly in a controlled sandbox. Recommendation flows need provenance, audit trails, and explicit decision boundaries. Once a system can execute actions—or orchestrate work across domains—you need enterprise rails: the shared control plane for identity and non-human identities, least privilege, policy enforcement, safety scanning, data boundaries, observability, evaluation, cost controls, audit evidence, and containment. Managed harnesses can now supply many runtime primitives, but enterprise rails express your organization’s risk appetite and authority model across vendors and workflows.
2) Why the ecosystem is exploding (and why it will continue)
If all enterprises had the same workflows and risk profiles, the market would consolidate to one runtime. Instead, workflows differ by regulation, data sensitivity, integration surface, latency, cost, sovereignty, and failure tolerance. What has changed since April 2026 is where the specialization sits: model labs and hyperscalers increasingly provide managed harnesses and agent runtimes, while open protocols such as MCP and A2A reduce some integration friction. The competitive boundary is shifting from “which orchestration framework?” toward “which control plane, integration contracts, and operational evidence let us change models and runtimes safely?”
Agent architectures still need to match the use case, but fewer teams should build generic orchestration plumbing from scratch. Coding, research, customer operations, ITSM, and regulated workflows have different cognitive and security profiles; use managed runtime primitives where they are commodity, and reserve custom engineering for workflow logic, domain tools, policy, evaluation, and integration patterns that create differentiation.
The frontier itself is also moving faster. Model families now expose explicit cost/latency/effort trade-offs, stronger computer use, programmatic tool calling, and parallel agent execution. That makes “best model” a short-lived decision. The durable design is a routing and evaluation layer that can choose the right intelligence for each step and prove that a model or harness upgrade improves the business task before rollout.
The useful mental model: choose per layer, not per trend
- Stop asking “which framework is best?” Ask “which layer do we need to own vs outsource?”
- Keep portability in the contracts: tool interfaces, evaluation harnesses, and policy gates.
- Treat observability and FinOps as first-class features, not afterthoughts.
3) Agent archetypes: Why architecture differs by use case
Not all agents are built the same. A knowledge assistant operating on internal documentation has different risks and architecture needs than an ITSM remediation agent that can change production systems.
As you move right (more integrations) and up (more actionability), your architecture must shift. Read-heavy agents demand retrieval quality, provenance, and access control. Action agents demand least privilege, approvals, idempotency, and audit-grade logs. Cross-domain orchestrators demand an event backbone, coordination patterns, and portfolio-level governance.
4) The agent stack: What you choose vs what you must operate
A common failure pattern is still “we picked a model and built a prototype,” but the build-vs-buy boundary has moved. Production agents require retrieval and memory, tool integration, state, sandboxing, observability, evaluation, safety, and cost controls. Many of these can now be consumed as managed harness capabilities. The goal is therefore not to own every layer; it is to make the safe path the default and keep stable contracts around tools, policies, identity, telemetry, and evals so the runtime can evolve underneath you.
5) Cost, latency, and reliability: Why routing becomes inevitable
As usage grows, cost and latency become workflow economics rather than token economics. Frontier providers now expose families of models and effort levels, and agent runs can multiply inference through planning, tool calls, retries, subagents, and verification. Route by task difficulty and risk: use efficient models for well-specified work, frontier reasoning where uncertainty justifies it, and human or deterministic gates where consequences are high. Measure cost per successful outcome—not cost per token.
6) A pragmatic selection rubric (use-case driven)
Before you pick tools, answer these questions in order:
- Outcome: What business metric changes if this works (cycle time, cost, risk, conversion)?
- Workflow type: Does the agent read, recommend, or execute?
- Risk tier: What data does it touch, and what actions can it take?
- Non-functionals: What are the SLOs/SLA, audit requirements, residency constraints, and cost caps?
- Integration surface: Which systems of record/engagement does it need (CRM/ERP/ITSM/Git), and is it event-driven?
- Reuse strategy: What should become a reusable capability for the next 10 use cases (connectors, policies, evals, observability)?
Harness decision: Which runtime capabilities are commodity enough to buy—sessions, sandbox, memory, tracing, gateways—and which must remain enterprise-controlled?
Portability boundary: Which interfaces must survive a vendor change (MCP/A2A/tool contracts, identity, policy, telemetry, eval datasets, audit evidence)?
Avoid these three traps
- The “Everything Bot” trap: broad scope with weak controls. Start with 1–2 narrow action agents tied to cash-flow outcomes.
- The “Platform with no pull” trap: building a landing zone before you have a use case that creates adoption pressure.
- The "Messy Foundation" trap: Building clean AI on unvetted "Shadow AI" tools or messy data. To prevent this, Futurice uses a "Mess-O-Meter" to assess technical debt. If critical, we pause AI development to build a governed Lean Data Product first, ensuring agents run exclusively on pristine intelligence
What to do next
If you remember one thing: pick architecture from the use case backwards, not from the newest model or agent platform. Classify a small set of high-value workflows using the ladder in Figure 1, define the minimum enterprise rails, and decide explicitly which harness capabilities to buy versus own. The market will keep changing; those contracts are what let your architecture change with it.
In Part 2 of this series, we will dive into the friction that occurs when these probabilistic AI agents meet deterministic enterprise constraints, exploring security, architecture, and Service Level Agreements (SLAs).
