Agent Orchestration in the Enterprise: Coordination, Control and Scale
Panelists from SAP, Graphwise, AT&T and a global bank explained when an orchestration layer is worth its complexity, why deterministic code should enforce business rules, how to resolve conflicts between agents and what to monitor as agent systems scale.
By The AI Enterprise Magazine Team6 min read
Key takeaways
- Orchestration is for paths you can't predefine. Kumar said stable, deterministic processes are better served by conventional workflow automation.
- Models interpret, code enforces. Business rules belong in deterministic services, not prompts. "Reason only when you must and compute whenever you can," Trivedi said.
- Resolve conflicts in policy, not at runtime. Validate plans before execution, set loop limits and escalate to a person with the evidence.
- Trace every task. Watch execution, quality and business signals, and keep context windows well below their limits.
- Scale in stages. Start in observation mode, keep a shared agent registry with owners and identities, and expand autonomy as evidence builds.
Plenty of enterprise AI programs now describe themselves as agentic, but a set of AI assistants stitched to a few automated workflows is not the same thing as an orchestrated system of agents. That distinction opened "Agent Orchestration in the Enterprise: Coordination, Control, and Scale," an AI Connect webinar sponsored by SAP and Graphwise.
Brian Mink, co-founder and president of AI Connect, moderated a panel with Shubham Trivedi, Digital Solution Advisor at SAP; Vassil Momtchev, SVP of Product and Technology at Graphwise; Adarsh Naidu, Director of Architecture at a global banking company and a former principal architect at AWS; and Ram Kumar, Executive General Manager and Director of IT at AT&T.
When does an enterprise actually need an orchestration layer?
Kumar separated orchestration from conventional workflow automation. Buying a phone online follows a predefined sequence: pick a platform, a model, accessories, a plan, then check out. An orchestration layer goes further, he said. It interprets an objective, breaks it into a workflow, selects the agents and tools, manages dependencies, evaluates intermediate results and decides whether to continue, reroute or escalate to a person. He called this "intent-driven orchestration" and said it earns its place when the full path cannot be determined in advance, as when AT&T has to change network execution paths around a large event in downtown Atlanta. "If the process is stable and deterministic, conventional workflow automation is a choice," he said, adding that orchestration "must introduce more control than complexity."
Trivedi put it in terms of who does the coordinating. With a collection of assistants, "the human is the orchestrator." In true orchestration, the system breaks down the goal, carries context between steps and reconciles the results. For a single-shot question or a linear pipeline, he said, an orchestration layer is overengineering. His example was an accounts receivable process in which one agent reads the request, another reads the books and a third combines both to clear disputes or apply a cash payment.
Naidu described the banking version. Sending $100 touches five to ten applications under the hood, from payments and core banking to digital channels, and agents in each of those platforms need a governed, auditable way to talk across boundaries. That means building a control plane with an agent registry, a workflow engine and a policy engine, not just writing agent code.
Momtchev advised teams to check whether their use case is complex enough to justify multi-agent orchestration at all. The benefit of splitting work across agents is isolation, he said: one agent supplies information, another acts as a guardrail and a third checks for personally identifiable information, so a single error does not cascade through one long chain.
How should work be divided between models, agents and deterministic code?
Kumar's guiding principle was to use models for interpretation and deterministic components for control. A model may read a customer's intent and recommend an action, but deterministic services should validate eligibility and execute the transaction. "The agent should not recreate the authoritative business rule through prompting," he said. He recommended starting with the simplest viable architecture, since every added agent creates another identity, handoff and possible failure.
Trivedi's rule was "reason only when you must and compute whenever you can." Anything with a correct answer that a lookup or simple math can produce should go to a deterministic service, which is cheaper, testable and auditable. Momtchev added that evaluation criteria should come before architecture: "if you cannot measure something you cannot develop it." Naidu reminded the audience that enterprises have run orchestration for data and business processes for more than a decade, so agent orchestration is that same discipline with added controls, which matter most in regulated industries.
How do you tell whether a multi-agent system is ready for production?
Answering an audience question, Naidu said the success criteria have to be defined at design time and tied to total cost of ownership and business value. "If you are starting not from the end, it is a big problem," he said. Kumar said each agent needs a clear objective and a period under human oversight before it reaches production. Trivedi noted that vendors, SAP included, now ship pretested agents with mapped guardrails and monitoring, which can shorten that path.
How should orchestration handle conflicting agents?
Trivedi said conflicts should be caught before execution by validating every plan against schema and policy and checking the task graph for cycles. He recommended a reconciliation step with clear tie-breakers, such as source authority or recency, loop limits to stop agents burning tokens, and escalation to a person when confidence is low. Kumar agreed that conflict handling belongs in the orchestration policy, not in a runtime debate between agents. The right response to an ambiguous conflict, he said, is to stop safely and hand a person the summary and evidence.
Momtchev pointed to a less visible cause. Agents often disagree because they were grounded in bad data, such as an MCP endpoint returning an unexpected record, so the fault sits in a different part of the system from where the conflict appears. Naidu framed coordination as a protocol question, citing agent-to-agent and MCP protocols, and said conflict resolution is continuous rather than a one-time setup.
What should teams monitor in agent orchestration?
Kumar described layers of observability: operational health (latency, availability, token and infrastructure cost, retries and timeouts), agent behavior (model and prompt versions, tool choices, data access, handoff frequency and circular loops), quality and risk (task completion, accuracy, policy compliance, unauthorized tool attempts and exposure of sensitive data) and business outcomes. Teams should be able to reconstruct any decision: what evidence an agent used, what it did and where the workflow began to fail.
Momtchev's practical tip was to watch context size. He suggested keeping agents to roughly 10 to 30 percent of their maximum context window, since overloaded context is where agents "start to behave really weird," and to watch for MCP tools that are called repeatedly. Naidu said observability is a day-one priority in banking, treated as part of security, with tracing tools such as Phoenix used to follow an agent's reasoning end to end. Trivedi grouped the signals into execution, quality and business, with one trace per task across every agent and tool. "If you can't trace it, you can't trust it," he said, and tied his receivables example to a 10 to 20 percent cut in days sales outstanding.
Where do governance and human oversight fit?
Momtchev said governance starts before any agent is built, because agents cannot be governed on top of data sources with no clear owner. Trivedi placed guardrails at input, action and output, tiered by risk: low-risk, reversible actions can run on their own, while payments, disbursements and external communications need a human approver, with every action, rationale and approver logged. Kumar called for a distinct identity for every agent, least-privilege access and limits on tool chaining. Naidu said at least one point in the process must have a person who sees what is being approved, and that regulated industries are now trying to automate governance so it speeds delivery rather than slowing it.
What changes when agents scale across the enterprise?
Momtchev warned that externally hosted models can regress or be retired without notice, and recommended smaller, locally hosted models where predictability matters. Trivedi recommended a shared agent registry with ownership and identity, a regression harness, tracing and cost governance before scaling, so teams stop building duplicate agents in silos. Kumar advised scaling in stages, starting in observation or recommendation mode and expanding autonomy only when evidence shows readiness. Naidu closed on adoption: agents that the business is not asking for will not scale, however impressive the technology.
Frequently asked questions
What is agent orchestration?
Kumar described it as a layer that interprets an objective, breaks it into a workflow, selects agents and tools, manages dependencies and decides whether to continue, reroute or escalate to a person.
When do enterprises need agent orchestration?
When a workflow spans several specialized capabilities and its full path cannot be set in advance. For linear pipelines or single-shot questions, panelists called it overengineering.
How should conflicts between AI agents be resolved?
Validate plans against schema and policy before they run, use tie-breakers such as source authority or recency, set loop limits and escalate low-confidence cases to a person.
What should teams monitor in multi-agent systems?
Operational health, agent behavior such as tool choices and handoffs, quality and risk signals, context window size and business outcomes, with one trace per task.
This article is based on remarks by Brian Mink, Co-founder and President, AI Connect (moderator); Shubham Trivedi, Digital Solution Advisor, SAP; Vassil Momtchev, SVP, Product and Technology, Graphwise; Adarsh Naidu, Director, Architecture; Ram Kumar, Executive General Manager and Director, IT, AT&T at AI Connect webinar on November 12, 2026. More coverage: Webinars.
Filed under: Agentic AI, AI Governance & Trust, Observability & Data Quality
