How to build a shared AI agent platform without over-engineering

The first prototype can hide an agent-by-agent infrastructure tax

A contained first AI workflow can reasonably own its own authentication, tool wiring, logging and evaluation. The problem appears when the second and third workflows rebuild the same plumbing with slightly different rules. What looked like three useful projects becomes three identity models, three permission schemes, three observability paths and three ways to handle a production failure.

AWS published a Wood Mackenzie case study on 17 September 2026 that makes this problem concrete. AWS says three Wood Mackenzie applications were heading toward separate agent stacks, each recreating runtime, identity, observability and model wiring. Wood Mackenzie instead built APEX, a shared agentic platform that centralises cross-cutting controls while product teams keep their focus on the business logic that differentiates each application.

The useful lesson for a mid-market business is not to copy the entire APEX stack. It is to notice which parts of agent delivery are becoming repetitive and turn those parts into a reusable control layer before duplication becomes the default architecture.

What should become shared infrastructure

The shared layer should contain controls that are common across several workflows and expensive or risky to implement inconsistently. It should make the next workflow easier to ship without granting broader authority than that workflow needs.

More columns → Swipe, or focus the table and use the arrow keys.

Keep the business workflow specific

A shared platform does not mean one giant agent. Business rules, prompts, inputs, outputs, exception logic, domain context, service levels, owners and human handoffs should still be designed around the actual process. The shared layer should remove duplicated plumbing, not erase the differences that make one workflow safe and useful while another needs a different boundary.

This separation also reduces blast radius. A change to an enquiry-triage prompt should not change how a document-review workflow interprets obligations. A new CRM permission rule may be shared, but the business decision built on top of that permission remains local to the workflow that uses it.

• Business rules and decision criteria.
• Workflow-specific prompts and context.
• Inputs, outputs and exception logic.
• The named owner, SLA and escalation path.
• Human approval for the consequences unique to that process.

A practical mid-market example

Consider an illustrative property or professional-services business with two AI workflows. The first triages inbound enquiries, retrieves CRM context, prepares a response and routes the lead to the right person. The second reviews documents, extracts obligations and flags exceptions for a human reviewer.

The two workflows can share user identity, CRM permissions, document connectors, logging, an approval framework and the underlying evaluation infrastructure. Their business logic still differs. The enquiry workflow cares about lead state, routing and follow-up. The document workflow cares about evidence, obligation extraction and exception handling.

That is the point of the shared layer: the second workflow starts with controls and integrations the business already trusts, while the process-specific logic remains bounded to the job it is meant to perform.

Use a scaling test before the next agent project

Before the next workflow is scoped, inventory what agent number one already required. Authentication, system connectors, logging, evaluation, guardrails and deployment are good candidates for reuse if the same requirement is appearing again.

Then ask whether a policy or permission change can be applied once. If every workflow requires its own manual change when access rules, logging requirements or evaluation criteria evolve, the business is carrying architectural duplication that will become more expensive with each new agent.

1. List the controls and connectors built for the first production workflow.
2. Mark which of them are genuinely common to a second workflow.
3. Separate reusable controls from workflow-specific business logic.
4. Define one governed path for identity, tools, evaluation, logging and releases.
5. Measure whether the second workflow actually starts faster and with fewer duplicated components.

Avoid over-engineering the shared layer

A mid-market business does not need to recreate Wood Mackenzie's APEX platform or the full Amazon Bedrock AgentCore architecture to benefit from the principle. Start with repeated controls in workflows you are actually shipping. Standardise only what is genuinely common and keep the platform thin enough that teams can still change business logic quickly.

Premature abstraction creates its own tax. A generic connector framework that nobody needs, a policy system built for hypothetical agents or a central platform that every team must wait on can become a new bottleneck. Reuse should follow evidence from real workflows, not architectural ambition.

Measure whether the shared layer is earning its place

The platform should make useful workflows easier to operate, not merely produce a cleaner architecture diagram. Compare the second and third workflows with the first and include the operating work that remains after launch.

• Time to ship the second workflow compared with the first.
• Number of duplicated infrastructure components removed or reused.
• Intervention and review rate for each workflow.
• Tool failure rate and unresolved exceptions.
• Cost per accepted business outcome, not only model-token cost.
• Production incidents and time to identify their source.
• Time required to propagate a permission, policy or logging change across workflows.

Standardise the control layer, not the business

AWS and Wood Mackenzie's implementation is useful as a case study, not as a universal blueprint. Their architecture reflects an enterprise environment and Amazon Bedrock AgentCore. A smaller business should borrow the operating principle and scale the implementation to the complexity it actually has.

Amtec's public-safe operating principle is similar: reusable integration and control patterns should compound across systems, while authoritative business state remains in the source systems that own it and each workflow keeps a clear human approval boundary where consequence warrants it. That does not imply Amtec uses APEX or has deployed Wood Mackenzie's architecture.

The practical goal is simple: the first agent proves a use case. The second should improve the platform underneath future workflows rather than rebuild the same plumbing with a different name.

Common questions

Do we need a platform before building our first AI agent? Usually not. Prove one bounded workflow first, but avoid making identity, connectors, evaluation and logging impossible to reuse later.

What is the first component to standardise? Identity, permissions and source-system access are often high-leverage because they determine what every future workflow can safely read and do.

Should every agent use the same model? No. The shared layer can remain model-agnostic where practical while model choice varies by task and workflow.

Does a shared platform mean one giant agent? No. Prefer bounded workflows sharing common infrastructure over one agent with broad authority.

How do we know the platform is too complex? If the shared layer takes longer to change than the workflows it is meant to support, or teams bypass it to ship useful work, it has become part of the problem.