Part 3 — The Futurice Method: Assess | Gap | Roadmap | Scale Agents (Q1–Q4)

1) The 5-phase maturity model (customer-centric)

Maturity isn’t a vanity score. It is a delivery strategy: different phases require different architecture priorities and proof of readiness. In Futurice practice, we continue to see a five-phase adoption pattern—Exploring → Experimenting → Formalizing → Optimizing → Transforming—but the meaning has evolved. Formalizing now includes managed-runtime selection, agent identity, eval/release gates, and observability; Optimizing adds routing, cost-per-outcome and continuous improvement; Transforming is about redesigning workflows and operating models around human–agent collaboration, not simply adding more autonomous agents.

2) Workload vs Company: What you build vs the rails that make it repeatable

Separating Workload capabilities from Company capabilities is crucial:

• Workload layer = the AI product/use case: orchestration, retrieval, tool use, UX, use-case metrics.

• Company layer = enterprise rails: the organization-wide control plane for agent identity/NHIs, authorization and delegation, policy packs, data boundaries/DLP, tool and connector governance, containment/egress, observability, eval/release gates, FinOps, audit evidence, and incident controls.

This split ensures Company work is driven by real adoption pull, while still compounding into platform capability over time.

The Workload/Company split is even more important now that managed harness platforms package sessions, memory, sandboxing, tools, gateways, tracing, and optimization. Those services can accelerate both layers, but they do not erase the boundary. The Workload still owns business behavior and outcome metrics; the Company still owns authority, risk appetite, evidence, and cross-use-case controls.

That is good news for delivery speed. The roadmap no longer needs to assume that every capability is built internally. For each gap, choose one of four treatments: consume a managed capability, configure a company rail, build a differentiating component, or defer it because the use case does not need it. Keep portability at the seams—identity, policy, tool contracts, telemetry, evals, and workflow state—so your capability library survives vendor churn.

The 2026 buy-vs-build rule: own differentiation, consume plumbing

A pragmatic default is to buy or consume commodity harness capabilities—durable sessions, sandbox execution, generic memory, basic tool gateways, tracing infrastructure—when the managed service satisfies security, residency, interoperability, and economics. Retain company control over business process semantics, system-of-record connectors with side effects, authorization policy, sensitive retrieval boundaries, evaluation criteria and datasets, audit evidence, and cross-vendor governance. Build custom orchestration only where it encodes differentiated workflow behavior or a requirement the managed runtime cannot meet. This prevents both platform-first overengineering and accidental lock-in.

3) Enablement stories per stage: Outcome-led capability building (AWS-inspired)

AWS prescriptive guidance recommends aligning capability “stories” to business outcomes, assessing readiness, and building roadmaps from missing/partial stories. We apply the same approach to agentic AI: select outcomes, work backwards through maturity stages, and treat each capability as a reusable unit.

4) The assessment and gap analysis: Turning context into a backlog

The assessment combines business discovery with technical evidence collection. The goal is to answer: where are you today, what outcome do you want next, what must be true to ship it safely, and which missing capabilities should be bought, configured, or built? In 2026, evidence should include agent/tool inventories, identity and delegated-authority paths, production traces, eval results, incident/rollback mechanisms, cost per successful outcome, and vendor/runtime dependencies—not only architecture diagrams.

5) Roadmap generator: Q1–Q4 execution plan (workstreams × quarters)

Once you have Missing/Partial items, roadmapping becomes dependency-driven: group them into enablement projects, decide buy/configure/build, and sequence incremental usable releases. Step 1 should deliver a real outcome with minimum viable rails; later steps expand autonomy, integrations, resilience, evaluation depth, and reuse. Quarters remain useful for planning, but the roadmap should be expressed as Step 1 → Step 2 → Step 3 so a customer can start in any calendar quarter without changing the logic.

Generating a pragmatic roadmap (why generic plans fail)

Generic roadmaps fail because company contexts—and now platform choices—are wildly diverse. Futurice uses the FAMM assessment workbook and capability library to evaluate Agent Build, LLMOps/AgentOps, Security, Data/Retrieval, integrations, and Company rails. The output is a traffic-light enablement roadmap grounded in selected use cases. A team may be able to build an action agent but still lack agent identity, approval boundaries, eval gates, or auditable tool execution; those become Step 1 dependencies before broader autonomy. The same method prevents the opposite mistake: building a full internal agent platform when a managed harness already satisfies the requirement.

6) Why Futurice accelerates adoption (without sacrificing control)

Acceleration comes from reusable assets and delivery discipline, not from owning every layer. Futurice’s approach should leave behind a capability library: landing-zone IaC, policy and eval packs, agent identity patterns, governed connector/MCP templates, tool gateways, observability schemas, routing/cost controls, incident playbooks, and architecture decision records for managed-vs-custom capabilities. The goal is a paved road that lets the next use case inherit controls and evidence rather than restart from a sandbox.

For clients entering the Formalizing phase, Futurice deploys a Secure AI Landing Zone: a pre‑architected Infrastructure‑as‑Code foundation that is secure‑by‑default (standard identity for agents, policy packs, centralized logging and API gateway patterns, private connectivity patterns, and a semantic firewall/DLP layer). It removes the infrastructure tax so teams can move from local sandbox to safe production quickly—and reuse the same rails for every new use case.

Even with a managed agent runtime, enterprises still need a secure-by-default landing-zone posture: private connectivity where required, identity boundaries, policy distribution, audit evidence, secrets handling, connector governance, and least-privilege access to systems of record. Managed harnesses accelerate the execution substrate; the landing zone and Company rails standardize how that substrate is allowed to touch the enterprise.

Conclusion: The agentic era rewards structural capability

Success in the agentic era is still not governed by adopting the flashiest multi-agent swarm. By September 2026, the stronger lesson is that frontier intelligence and managed harnesses are becoming abundant. Scarcity has moved to organizational capability: redesigning workflows, granting useful authority safely, integrating proprietary context and systems, measuring outcomes, and continuously improving agents under governance.

The Futurice AI Blueprint therefore becomes more relevant, not less: maturity assessment, use-case-first gap analysis, explicit buy/configure/build decisions, reusable accelerators, and incremental roadmaps give enterprises a way to absorb rapid vendor progress without rebuilding their strategy every quarter. The objective is a repeatable path from PoC → product → industrialized AI service, where each new agent inherits the company rails, evidence, and operating model needed to create autonomous value safely.

References

1. strategy-aws-data.pdf — AWS prescriptive approach: align capability stories to outcomes and build roadmaps from gaps.
2. The New Stack — “AI Agent Harness Pricing Split” (Apr 2026): thenewstack.io/ai-agent-harness-pricing-split/
3. Anthropic Claude Platform release notes — Claude Managed Agents public beta (Apr 8, 2026): platform.claude.com/docs/en/release-notes/overview
4. Anthropic Engineering — “Scaling Managed Agents” (harness design patterns): anthropic.com/engineering/managed-agents
5. OpenAI — “The next evolution of the Agents SDK” (model-native harness + native sandbox execution) (Apr 2026): openai.com/index/the-next-evolution-of-the-agents-sdk/
6. Google Cloud — Vertex AI Agent Engine overview + pricing (sessions/memory/code execution billing): docs.cloud.google.com/agent-builder/agent-engine/overview ; cloud.google.com/vertex-ai/pricing
7. Microsoft — Foundry Agent Service pricing / hosted agents and Code Interpreter sessions: azure.microsoft.com/pricing/details/foundry-agent-service/ ; learn.microsoft.com/azure/foundry/agents/
8. AWS — Amazon Bedrock AgentCore docs + product page: docs.aws.amazon.com/bedrock-agentcore/ ; aws.amazon.com/bedrock/agentcore/