AI agents are moving from answering questions to performing tasks.

• A customer service agent can retrieve information, update a case, and draft a response.
• A claims agent can analyze documents, compare evidence, and recommend a next step.
• A supply chain agent can monitor inventory, investigate disruptions, and coordinate actions across systems.

As these workflows become more complex, a single agent may no longer be enough.

Instead, enterprises are beginning to explore multi-agent architectures in which one agent can delegate specific tasks to other specialized agents, tools, or models. This is an important direction for enterprise AI, in which complex workflows are broken into smaller tasks that can be assigned and coordinated across agents.

But adding more agents doesn’t automatically make an AI system more capable. It can also make the system harder to secure, evaluate, operate, and control.

The important question becomes: How does an AI agent know what to delegate, which agent should handle it, what information that agent actually needs, and when the result should be questioned?

This is where agent delegation becomes an enterprise architecture problem.

Google Cloud’s recent study on AI delegation highlights 4 important principles:

1. Delegated work should be verifiable.
2. Tasks should be matched with appropriate models and tools.
3. Sensitive data should be protected.
4. Agents should be able to introduce ‘dynamic cognitive friction’ when a request is ambiguous or warrants additional scrutiny.

Kartaca’s eight-step blueprint builds on those principles and translates them into a practical enterprise architecture for designing, governing, and operating multi-agent systems.

Why Agent Delegation Changes Enterprise AI

Consider a simple customer request: “A customer wants to change their insurance policy and has submitted several documents. Review everything, determine what needs to change, check whether the request is valid, update the policy, and notify the customer.”

A traditional application might implement this as a predefined workflow. An agentic system could approach it differently.

A coordinating agent might determine that the task requires:

• Retrieving the customer’s policy
• Classifying submitted documents
• Extracting relevant information
• Checking policy rules
• Comparing the request with existing customer data
• Determining whether additional information is required
• Updating the policy
• Generating a customer response

Each task could potentially be handled by a different agent, model, or deterministic service. That creates flexibility and a chain of decisions.

If the first agent gives the second agent too much information, the security risk increases. If the wrong model handles a task, cost or accuracy can suffer. If an agent delegates an ambiguous instruction without questioning it, an error can propagate through the entire workflow. This is why enterprise multi-agent AI needs a delegation framework.

The Eight-Step Enterprise Agent Delegation Blueprint

1. Decompose the Task

The first job of an orchestrating agent is understanding what actually needs to happen.

Rather than sending a complex objective to a single powerful model, the system should break it into smaller, meaningful tasks that can be assigned to the appropriate agent, tool, or service.

Google DeepMind and Google Cloud refer to this concept as contract-first decomposition. The objective is to break work down into tasks that can be reliably verified.

For an enterprise, this means asking:

• What is the overall business objective?
• Which steps are independent?
• Which steps depend on previous results?
• Which tasks require reasoning?
• Which can be handled deterministically?
• Which require access to enterprise data?
• Which decisions require human judgment?

The result should be a delegation graph, rather than an undefined chain of prompts.

For example:

Customer request → Orchestrator → Document Agent → Policy Agent → Validation Service → Decision Agent → Human Review → Customer Response

The architecture becomes easier to understand, test, monitor, and govern when every delegation has a defined purpose.

2. Define the Contract

Delegation needs a clear contract between the delegating agent and the agent receiving the task. The contract should establish what is being requested, what information is being provided, what the receiving agent is expected to return, and what conditions determine success.

For example:

• Task: Validate a submitted insurance document.
• Input: Document ID, document type, policy ID, required fields.
• Expected output: Valid or invalid, missing information, confidence score, validation evidence.
• Authority: Read-only access to the submitted document.
• Success criteria: All mandatory fields verified against the defined policy rules.

This approach creates a boundary around every delegated task and gives the enterprise something important: a way to evaluate whether an agent has actually completed its assignment.

Establishing a clear contract transforms delegation from a set of disjointed prompts into structured, verifiable units of work.

3. Select the Right Agent or Model

Not every task needs the most powerful model available.

It is critical to match tasks with the right model or endpoint, balancing reliability and capability against cost. A simple task, such as formatting information, doesn’t necessarily require a sophisticated reasoning model, whereas a complex task may justify one. This creates the need for model and agent routing.

A delegation layer could consider:

• Task complexity
• Required accuracy
• Latency requirements
• Data sensitivity
• Model capabilities
• Cost per request
• Availability
• Required tools
• Historical performance

For instance, a lightweight model could classify incoming documents, while a stronger reasoning model handles an ambiguous policy interpretation.

A deterministic API could retrieve a customer’s balance instead of asking an LLM to reason over financial data. This isn’t simply a cost optimization exercise. Choosing the right execution method can also improve reliability.

The architecture should give agents access to the right capability for the job, rather than treating every problem as an LLM problem.

4. Share Only the Required Data

Delegation creates another fundamental question: “How much information should the receiving agent see?” The answer should be as little as possible.

Restricting sub-agents to least-privilege access is a core architectural necessity for enterprise AI. Passing full context or unmitigated authority downstream inflates attack surfaces, degrades system responsiveness, and threatens overall operational integrity.

Imagine a payroll agent asking another agent to calculate an employee’s bonus eligibility. The second agent might just need salary band, role, performance information, and the relevant compensation rules, not the employee’s entire HR record.

This principle should apply across the architecture: Minimum data. Minimum permissions. Minimum authority.

That requires enterprise-grade identity and access controls for agents, not just users. Agent identities should be tied to defined permissions and actions. Access should be scoped to the task. Sensitive information should remain protected as it moves through the delegation chain.

A robust enterprise framework demands rigorous agent identity management and clearly scoped delegation models. Agents should operate within clearly defined authority boundaries, whether acting on their own behalf or on behalf of an authorized user.

5. Verify the Result

Delegation only works when the result can be trusted. An orchestrating agent shouldn’t simply receive an answer from a sub-agent and pass it downstream. It should have a way to determine whether the task was completed successfully.

Verification can take several forms:

• Schema validation
• Rule-based checks
• Confidence thresholds
• Cross-checking against enterprise data
• Automated evaluation
• Secondary model review
• Business-rule validation
• Human review

For deterministic tasks, verification may be straightforward. For example:

• Did the policy number exist?
• Was the required field present?
• Does the calculated amount match the business rule?

Other tasks are inherently subjective. A generated customer response may be factually correct but still fail brand or regulatory requirements. This distinction matters.

Not every task can be verified in exactly the same way. Some tasks require subjective judgment, making human expert intervention an important part of the delegation architecture.

6. Introduce Friction When Something Looks Wrong

Enterprise AI systems are often designed to make interactions frictionless. Agentic systems need to know when friction is useful.

Google Cloud describes this as dynamic cognitive friction. An agent should be capable of questioning an instruction when it is ambiguous, inappropriate, or potentially harmful, rather than automatically passing it along the delegation chain.

Consider an accounts-payable workflow.

1. An agent receives an invoice and is instructed to pay it immediately.
2. The invoice appears legitimate, but the bank account differs from the supplier’s historical account.
3. A purely compliant system might continue.

A more appropriately cautious system could pause and ask:

• Has the supplier’s payment information changed?
• Is there supporting documentation?
• Does the requested payment exceed an approval threshold?
• Should a human approve the change?

That moment of friction can prevent an error from becoming an action. The goal isn’t to make every workflow slower. It’s to make the system selectively cautious. High-confidence, low-risk tasks can proceed automatically. Ambiguous or high-impact tasks should trigger additional verification.

7. Escalate to a Human When Necessary

The most mature agentic architectures won’t try to eliminate humans from every workflow. They’ll use human expertise where it creates the most value. A useful way to think about this is:

Agent acts → Agent delegates → Agent verifies → Human decides

The exact point of escalation depends on risk and uncertainty.

• A customer-service agent may be able to resolve a routine address change automatically.
• A claims agent might prepare a settlement recommendation but require human approval for amounts above a certain threshold.
• A healthcare workflow may automate document summarisation while leaving clinical decisions to qualified professionals.
• A financial-services agent might identify a suspicious transaction but require an authorized employee to approve the next action.

This makes human oversight part of the architecture rather than an emergency fallback, and it gives enterprises a practical way to decide where to stop automation.

8. Monitor Cost, Performance and Outcomes

Once multiple agents are working together, traditional application monitoring isn’t enough. Enterprises need visibility into the entire delegation chain. For every task, organizations should be able to understand:

• Which agent initiated the task?
• Which agent received it?
• What data was shared?
• Which tools were called?
• Which model was used?
• How much did the task cost?
• How long did it take?
• Was the result verified?
• Was it delegated again?
• Did a human intervene?
• What was the final business outcome?

This creates an agent observability layer and enables optimization.

Perhaps one agent consistently sends simple tasks to an expensive model. Another might have a high failure rate when working with a particular document type. A third could be requesting more enterprise data than it actually needs.

Lacking comprehensive end-to-end visibility, identifying these behavioral trends remains a challenge. Robust observability turns delegation into an adaptable capability that organizations can systematically assess and refine over time.

This direction is already reflected in current enterprise agent platforms, such as the Gemini Enterprise Agent Platform, where the Agent Gateway can capture observability telemetry across agent interactions.

From Agent Orchestration to an Enterprise Architecture

These eight steps point toward a broader architecture for multi-agent AI.

At the center is an orchestration layer that understands business objectives, decomposes tasks, selects agents and tools, and coordinates execution. Around it sit several supporting layers.

Orchestration Layer

Responsible for:

• Task decomposition
• Agent selection
• Workflow coordination
• Delegation contracts
• State management
• Escalation decisions

Model and Tool Layer

Provides access to:

• Different AI models
• Deterministic APIs
• Enterprise applications
• Business services
• Search and retrieval tools
• Custom agents

The orchestration layer should be able to route each task to the capability that best fits it. This way, instead of using the same model or agent for every problem, the most appropriate execution path can be selected based on the task’s required accuracy, cost, speed, data access, and expertise level.

Data and Context Layer

Provides agents with trusted enterprise context from sources such as:

• Data warehouses
• Operational databases
• Documents
• Knowledge bases
• APIs
• Business applications
• Real-time data streams

This layer becomes particularly important because agents need trusted business context to make useful decisions. Enterprise data and context are foundational to agentic systems, and the challenge goes beyond access to ensuring that agents have the information and business rules they need for the task.

Identity and Security Layer

Controls:

• Agent identity
• User identity
• Delegated authority
• Data access
• Tool permissions
• Secrets
• Sensitive information
• Audit trails

Every agent should clearly answer the question: “Who authorized you to do this?”
Every action should clearly answer the question: “What were you authorized to access and change?”

Evaluation and Governance Layer

Provides:

• Automated evaluations
• Quality thresholds
• Policy enforcement
• Human approval workflows
• Auditability
• Risk controls
• Agent inventories
• Performance monitoring

This becomes increasingly important as organizations move from individual experiments to fleets of agents. Agent sprawl, governance, identity, and access are also important considerations for the agentic enterprise.

Observability and FinOps Layer

Tracks:

• Token consumption
• Model costs
• Latency
• Failure rates
• Delegation depth
• Tool usage
• Business outcomes

The goal is to understand not only whether an agent works, but also whether the overall system delivers sufficient value relative to its operational cost.

A Practical Decision Framework for Delegation

Before an agent delegates a task, the system should be able to answer eight questions to make delegation an explicit architectural capability rather than an implicit behavior.

Question	What it determines
1. What exactly needs to be done?	Task decomposition
2. What does success look like?	Delegation contract
3. Which capability is best suited?	Agent, model, or tool selection
4. What information is required?	Minimum data access
5. How will the result be checked?	Verification
6. What could make this request risky or ambiguous?	Cognitive friction
7. When should a human decide?	Escalation
8. How will we measure the outcome?	Observability

The Real Opportunity is Coordinated Intelligence

The next phase of enterprise AI won’t simply be about deploying more agents. It’ll be about creating systems in which agents can work together responsibly.

• A claims agent shouldn’t need to know everything about an enterprise to process a claim.
• A retail agent shouldn’t need unrestricted access to every customer record to recommend a product.
• A manufacturing agent shouldn’t be able to trigger a production change simply because another agent requested it.
• A financial agent shouldn’t automatically trust every instruction passed down a delegation chain.

Good agentic architecture creates boundaries around these interactions. It gives:

• Each agent enough context to perform its job, enough authority to complete its task, and enough constraints to prevent it from doing things it shouldn’t.
• The orchestrating system a way to verify, question, redirect, or escalate when circumstances demand it.

How Kartaca can help

For enterprises, building a multi-agent system is ultimately as much an architectural challenge as an AI challenge. The agents need access to trusted enterprise data, secure identities, modern application infrastructure, appropriate models, reliable APIs, evaluation frameworks, and observability.

Kartaca helps organizations build the cloud, data, AI, and application foundations required to move agentic AI from experimentation into production. This can include modernizing the underlying cloud infrastructure, building data platforms and BigQuery architectures, connecting enterprise data and applications, designing secure AI architectures, and developing AI assistants and agentic workflows that center on real business processes.

The result is an architecture in which agents don’t simply act autonomously. These agents know what to delegate, who should handle it, what information can be shared, how the result should be verified, and when a human should take over.

Contact us today to start building the foundation for enterprise AI that can scale with both capability and control.