Beyond Wrapper Products: Enterprise Architecture Requirements for AI Agents in 2027

A logistics operator showed us an AI assistant that could summarise delivery exceptions perfectly. It could not update a shipment, check whether the user was allowed to reroute it, or explain which source system supplied the status. The demo worked because the agent only spoke. Production stopped at the point where software had to act.

That is the dividing line for 2027. A wrapper product sends prompts to a model and returns text. An enterprise agent observes context, plans a sequence, calls approved tools, records what happened, and stops when its authority ends. The architecture has to carry those responsibilities; a larger model will not supply them.

Gartner’s May 2026 forecast puts the consequence plainly: by 2027, 40% of enterprises will demote or decommission autonomous AI agents because governance gaps are discovered after production incidents. The problem is not a lack of AI experimentation. It is that teams are promoting prototypes into operational systems without designing the trust boundaries first.

Why most AI pilots never reach production

AI agents are the wrong choice when the workflow has no stable objective, no authoritative data source, or no owner willing to accept accountability for the action. A chatbot may still be useful in those conditions; an autonomous agent is not. We have seen teams spend months improving responses for a process whose policies changed weekly and whose source data could not be reconciled.

The common market answer is to add a human approval button. That is necessary, but it does not repair missing lineage, weak identity, poor tool contracts, or an absent audit trail. A human approving an opaque recommendation is still operating a system they cannot properly inspect.

Dataiku describes the enterprise distinction accurately: copilots suggest, while agents act through multi-step workflows, external tools, memory, and planning. That difference changes the architecture and the risk owner. A wrapper can be evaluated on response quality. An agent must also be evaluated on whether it selected the right record, called the right system, respected permission boundaries, handled failure, and left evidence.

For a fintech software development team, the threshold is higher again. A useful answer about a payment, customer, or transaction does not authorise a change to that record. In Singapore financial services, MAS TRM makes technology risk management and accountability operational concerns. In Australia, APRA CPS 230 makes third-party and operational resilience obligations relevant when an external team or platform supports a critical operation. The organisation remains accountable for the code path and the business outcome; delegating implementation does not delegate the obligation.

Our position is direct: do not fund an autonomous agent until the business can name the action, the authority, the data source, the approval boundary, and the rollback path. If those cannot be named, build an observe or advise capability instead.

Data foundations: lineage, quality, access

Enterprise AI readiness begins with an answer to one question: can the agent identify which data it used, how fresh that data is, and whether the requesting identity was allowed to see it? If the answer is no, the organisation has a model experiment, not a production foundation.

The failure usually appears as a confident contradiction. A store manager asks why an order is delayed. The agent retrieves a warehouse event from one system, an old delivery promise from another, and a customer note from a third. It produces a fluent explanation with no indication that the timestamps use different time zones or that the order was rebooked. The business sees an answer; the customer receives a false commitment.

A data pipeline for AI agents therefore needs more than ingestion and vector search. It needs identity-aware retrieval, source ownership, freshness metadata, schema controls, reconciliation rules, and a way to expose uncertainty. Retrieval-augmented generation is not a substitute for data management. It is a consumer of whatever data discipline the enterprise has already built.

We start readiness work by tracing one high-value workflow from request to action. The trace identifies every system touched, every field relied upon, and every point where a human currently resolves ambiguity. That exercise often finds that the missing component is not an LLM. It is a reliable event, a canonical customer identifier, or an owner for a stale reference table.

Teams building this layer should separate four forms of access:

• Discovery access: what the agent may know exists.
• Read access: which records and fields it may retrieve for this identity and task.
• Write access: which state changes it may request, not merely which API it can reach.
• Delegated authority: which action may proceed only after a named person, policy engine, or second system approves it.

Lineage must travel with the answer and the action. A production trace should show the user identity, policy version, source records, retrieval time, model and prompt versions, tools called, arguments passed, approval decision, result, and any fallback. This is the practical core of data governance and data management for AI systems, not a documentation exercise performed after launch.

Related:OmniStack’s technology insights, useful for adjacent guidance on software delivery, data, and engineering capacity.

Tool and action boundaries for agents

An enterprise agent should never receive broad application access and be trusted to behave. It should receive narrow, typed tools whose permissions, inputs, outputs, and failure states are explicit. The tool boundary is the point where a language model becomes an operational actor.

The most dangerous design we encounter is a single “execute” function that accepts a natural-language instruction and routes it internally. It is convenient for a demo and impossible to govern at scale. A payment refund, customer notification, inventory adjustment, and account closure should not share one generic capability merely because the model can describe all four in the same sentence.

Use an action ladder. Observe agents receive read-only access and return results to the requesting user. Advise agents generate recommendations or drafts while a human executes the action. Act agents may perform bounded changes under policy. Coordinate agents may call multiple systems, but only within a defined workflow and with checkpoints. Gartner’s autonomy model makes the same essential point: controls must reflect both what an agent can do and the scope of access it has.

For legacy modernisation, the safest pattern is an anti-corruption layer around the old system. Do not expose undocumented database writes to an agent. Create an application service that validates the business rule, emits an event, records the actor, and provides a reversible operation where one is possible. The agent should call that service, not improvise around it.

Teams delivering these interfaces need product engineering and platform engineering in the same room. A pod that owns only prompts will miss transaction semantics. A platform team that owns only APIs will miss the workflow’s human decision points. A delivery team covering application engineering, QA, UX, and DevOps can keep the action contract tied to the roadmap rather than leaving it between vendors. Where the work includes a new AI product or workflow, AI product and MVP engineering is relevant only when it includes these production boundaries, not when it stops at a model demo.

Match autonomy to action boundaries

Controls must reflect both capability and scope of access.

Evaluation, audit trail and human approval

Our verdict is simple: an agent is production-ready only when its decisions and actions can be tested before release and reconstructed after an incident. Accuracy scores alone do not meet that standard.

Implementation begins with a task-level evaluation set. Capture real requests, edge cases, prohibited requests, ambiguous records, permission changes, tool failures, and adversarial instructions. Each case needs an expected outcome, not merely an ideal answer. For an operations agent, the expected outcome may be “ask for the missing shipment identifier,” “refuse the write,” or “escalate to a named queue.” Refusal and escalation are successful outcomes when the authority boundary requires them.

Run evaluations at four layers:

1. Retrieval: did the system select the correct source records and respect access controls?
2. Reasoning: did the plan follow the workflow and identify uncertainty?
3. Execution: did the agent call the correct tool with valid arguments and handle errors?
4. Outcome: did the business state change correctly, with the required evidence and notification?

Human approval should be designed as a control, not a decorative interface element. The approver needs to see the proposed action, affected records, source evidence, policy result, uncertainty, and consequences of approval. A green button beside a paragraph of generated text is not meaningful review.

Audit data also needs retention and access rules. Store the prompt and response where appropriate, but prioritise the action trace: identity, policy, sources, tool calls, approvals, state changes, and timestamps. Sensitive data must not be copied into logs without a purpose. Financial services teams should map these records to their existing incident, change, access, and third-party risk processes rather than creating an isolated AI register.

Quality assurance must include model and system behaviour. A prompt change can alter tool selection. A source schema change can alter retrieval. A permission change can expose a new path. AI-driven quality assurance and testing can support coverage, but the test owner still needs domain cases and an agreed release threshold. Automation does not decide what “safe enough” means for a refund, a credit decision, or a warehouse release.

An 18-month readiness roadmap

Enterprise AI readiness is a sequence of ownership decisions, not a single platform purchase. The roadmap below assumes a business with legacy applications, multiple operating sites, and a constrained engineering team. The dates are planning windows, not a promise that every organisation should move at the same pace.

• Months 0-3, Select the workflow: choose one process with a stable objective, measurable failure cost, an accountable business owner, and a bounded action. Document the current human workflow and the systems involved. If no owner accepts the outcome, stop at an internal experiment.
• Months 3-6, Establish the data contract: identify authoritative sources, identifiers, freshness expectations, retention rules, access roles, and reconciliation failures. Build the read-only path first. Publish lineage with every result.
• Months 6-9, Build the tool boundary: expose narrow APIs with schemas, policy checks, idempotency, rate limits, dry-run modes, and explicit rollback or compensation. Keep writes disabled until the evaluation set includes denial, ambiguity, and failure cases.
• Months 9-12, Operate in advise mode: let the agent generate plans or drafts while people perform the action. Compare recommendations with actual decisions, record overrides, and identify where the workflow itself is inconsistent.
• Months 12-15, Introduce bounded action: automate only the low-risk state changes with clear policy outcomes. Require approval for exceptions, high-impact actions, and cross-system coordination.
• Months 15-18, Review autonomy: decide whether the agent should remain assistive, act within its existing boundary, or coordinate additional steps. Expand access only when evaluation, audit, incident response, and ownership are ready.

The delivery model matters during this period because the architecture crosses disciplines. A local senior engineer hired into a Singapore team carries base salary, 17% CPF, roughly 20% recruiting fee, and a three-month ramp before the first shipped increment under the supplied planning assumptions. Those are not the only costs; the larger issue is whether the roadmap can wait for the capability to assemble.

This is the distinction between renting headcount and buying delivered capability. Staff augmentation, body shopping, and per-hour developers place individuals inside an existing system and leave coordination with the client. A dedicated pod with a tech lead, QA, and DevOps responsibility owns a defined delivery outcome and keeps the same engineers aligned to the roadmap. The latter is not automatically right; it fails when the client has no product owner, refuses access to domain experts, or expects the pod to make unapproved regulatory decisions.

OmniStack’s model fits the second condition when the client needs continuity across application development, data, cloud, QA, and UX: the engineers are on our payroll and on the client roadmap, so delivery risk sits with us rather than with the client’s hiring pipeline. The client still owns business decisions, regulatory accountability, and acceptance of the outcome. That boundary should be written into the operating model before the first agent reaches production.

In-house hire or delivery-owning pod?

A pod requires a client product owner and access to domain experts.

Where this approach fails

A dedicated engineering approach is the wrong choice when the organisation is trying to outsource accountability. A pod cannot compensate for a missing executive owner, an undefined process, or a risk committee that will not approve the action boundary. It also fails when the workflow changes faster than the business can establish policy, because continuity without a stable target becomes continuous rework.

Hiring in-house is the honest answer when the capability is a permanent strategic core, the company can maintain the surrounding platform and governance functions, and the domain knowledge must remain embedded in the organisation for the long term. That condition matters in regulated fintech, where internal ownership of risk, architecture, and control design may be more valuable than external delivery capacity.

A partner-led pod is the better answer when the problem is a temporary or expanding capacity gap: legacy systems need renewal, a data foundation must be built, and product delivery cannot pause while the company completes a full hiring cycle. The pod should transfer operational knowledge through documentation, pairing, runbooks, and shared incident response. It should not become a black box that the client cannot operate.

We reject the idea that every business needs a multi-agent platform. Many workflows need one bounded agent, a deterministic policy service, and a reliable integration layer. Multi-agent orchestration adds failure modes: delegation ambiguity, duplicated memory, conflicting plans, and harder audit trails. Add another agent only when the separation of responsibility is clearer than a single workflow service.

For teams working across sites, the failure pattern is usually organisational before it is technical. A head office approves an agent for customer support while local operations maintain different exception rules. The model behaves consistently; the business process does not. The architecture must represent tenant, region, role, language, operating calendar, and local policy explicitly. A global prompt is not governance.

The enterprise architecture decision for 2027

The enterprise agent stack should be treated as a controlled application platform with a model inside it. The minimum architecture includes identity, policy, data lineage, retrieval, tool contracts, workflow orchestration, evaluation, observability, incident response, and accountable ownership. A model endpoint is one component, not the product.

Use this decision test before approving production work:

• Can we name the business outcome and the person accountable for it?
• Can we identify the authoritative data sources and show freshness and lineage?
• Can we state exactly what the agent may read, write, approve, and refuse?
• Can every tool call be validated, logged, replayed, and rolled back or compensated?
• Can a human reviewer see evidence and consequences before approving a high-impact action?
• Can QA test retrieval, policy, execution, and outcome separately?
• Can the operating team respond when the model, source data, integration, or policy changes?
• Can the organisation meet MAS TRM, APRA CPS 230, and its own access, change, incident, and third-party controls?

If the answer is no, reduce autonomy rather than increasing model capability. Start with observe or advise mode, fix the named constraint, and repeat the evaluation. That sequence produces less impressive demos and more systems that survive contact with customers, regulators, and operations.

For a practical first move, book a data readiness assessment for one workflow and require the output to include the source map, identity model, action boundary, evaluation cases, and accountable owner. The next decision is not which model to buy. It is whether the organisation is ready to let software change a real business state, and who will answer when it does.

production readiness gates

1. accountable business outcome — Name the outcome and its accountable owner.
2. authoritative data sources — Show source freshness and lineage.
3. explicit authority boundaries — Define permitted reads, writes, approvals, and refusals.
4. controlled tool calls — Validate, log, replay, and reverse or compensate tool calls.
5. evidence and evaluation — Require informed human review and separate QA tests.
6. operational readiness — Support incident response, change, and regulatory controls.

If a gate fails, reduce autonomy to observe or advise mode.

FAQ

What is the difference between an AI wrapper and an enterprise AI agent?

An AI wrapper sends a request to a model and presents the response. An enterprise AI agent can observe context, plan multi-step work, call controlled tools, change business state within defined authority, and produce an audit trail.

What data foundations do AI agents need?

They need authoritative sources, stable identifiers, freshness metadata, lineage, access controls, reconciliation rules, and retention policies. A vector index alone does not provide those controls.

How should companies govern AI agents in 2027?

Governance should be proportional to autonomy and access. Read-only observe agents need scoped access and logging; agents that advise or act need stronger policy enforcement, evaluation, approval, audit, rollback, and incident controls.

Should a fintech build AI agents in-house?

Build in-house when the capability is a permanent strategic core and the company can sustain the required platform, governance, and domain ownership. Use a delivery-owning pod when the immediate constraint is cross-functional capacity, provided regulatory accountability remains with the client.