An AI agent that handles one customer email makes a convincing demo. Tomorrow’s inbox raises harder questions. What happens when two customers share a name, the contract document is outdated, or a system times out after saving a change?
A provider can restore its service while your customer’s request remains unresolved. Someone in your organisation still owns that outcome.
That is the starting point for this ETX2 series, written for people choosing, building, and taking responsibility for AI in business processes. There may be a hundred ways to build an agent. I want to understand which ones earn their place.
Start with the process
Imagine a customer asking why their insurance premium increased.
Identify the policy, retrieve the renewal notice, draft an explanation, and obtain approval: we can prescribe those steps. My default is a workflow, using a model where language understanding or drafting helps.
Now suppose the notice contradicts the policy record. Choosing which correspondence to inspect and whether to investigate further gives an agent meaningful discretion.
Vendor definitions differ in emphasis. Anthropic distinguishes predefined paths from model-directed action; OpenAI emphasises planning, tools, and context; Microsoft combines agents with workflows. For this series, an agent uses a model to choose actions towards a goal, examines the results, and decides what to do next, within boundaries we set. Anthropic’s recommendation to try simpler solutions first is a useful starting discipline.
An email trigger only determines when work starts. It says nothing about who chooses the subsequent steps. Our design begins with a prescribed workflow and delegates the uncertain investigation.
Separate the platform decision from the design decision
Two questions help organise the landscape, but they do different jobs.
Who operates the runtime? This helps narrow the platform shortlist and the operational responsibilities your team takes on.
Who selects the steps? This is primarily a design decision inside the chosen platform. Many products support both prescribed sequences and model-selected actions. You can change that balance without necessarily changing vendors.
The workflow with a delegated investigation is therefore a design we impose. Buying an agent platform does not make that decision for us.
For runtime ownership, the main options look like this. “Your team” includes operating software on rented cloud infrastructure; the following list describes the listed deployment route.
Copilot Studio → Runtime operated by Microsoft → build with Visual agents and flows
OpenAI Responses API→ Your team → Custom model integration
OpenAI Agents SDK → Your team → Agent building blocks
OpenAI Agents API → OpenAI → Managed agent execution
Claude Messages API → Your team → Custom model integration
Claude Agent SDK → Your team → Agent building blocks
Claude Managed Agents → Anthropic → Managed agent execution
n8n / Dify → Either → Workflows and agents
LangGraph, self-hosted → Your team → Programmed execution graphs
For direct APIs, “runtime” means the application running the process; the provider still serves the model. The managed-agent entries describe provider-run orchestration; tools can still execute in your own environment. For n8n and Dify, “either” means choosing a hosted or self-hosted edition.
The cloud platforms also offer managed runtime options: Microsoft Foundry Agent Service, Amazon Bedrock AgentCore, and Google Gemini Enterprise Agent Platform. They belong on a shortlist shaped by identity, networking, and monitoring requirements. Google also offers the Agent Development Kit and visual Agent Studio. Microsoft, AWS, Google.
There is also a model-hosting choice. Self-hosting an application while calling an external model API still sends that provider the supplied context. Running an open-weight model locally through software such as Ollama adds responsibility for model serving, capacity, and updates.
Judge the build by its difficult cases
The authoring experience matters to build effort. No-code uses instructions, templates, and tools; low-code adds visual flows, expressions, and scripts; code gives us APIs, SDKs, and application logic. None removes the need to debug what happens.
Our first practical instalment will apply this to Copilot Studio: provider-operated execution, with prescribed steps around a model-directed investigation.
I use six questions to keep that evaluation grounded: build effort, access, decision scope, testability, cost, and failure ownership. Together, they cover what it takes to build the system and keep the business process working.
For our premium example, I care less about the first plausible draft than the ambiguous customer identity. A shared name must not be enough to select a policy. The evidence needs to show both that the correct records were retrieved and that access stayed within scope.
Missing or outdated evidence should lead to escalation. A polished explanation is a failure if the system has filled the gap with an invention. I favour bounded investigation and drafting, with an explicit approval before sending.
The timeout is another revealing test. If the write succeeded but its acknowledgement was lost, a retry can repeat the action. Durable execution helps preserve progress; preventing duplicate effects also requires support at the action boundary, such as a request identifier that the receiving service recognises across retries. Where that support is absent, the design needs reconciliation before retrying an uncertain action.
Alongside those cases, the comparison needs three practical records:
Integration effort, including custom work for the mailbox and policy system.
Completion quality, elapsed time, model and platform charges, and human review effort.
Named owners for incorrect advice, failed integrations, and unresolved requests.
The independent paper AI Agents That Matter shows why quality and cost belong together: accuracy-focused benchmarks can reward unnecessary complexity and expense. For me, a more elaborate agent has to demonstrate a worthwhile improvement over the simpler workflow.
Ownership needs more than a name in a document. The process owner decides when to suspend automated handling, technical support diagnoses integration failures, and an assigned business team takes unresolved requests. Service hours and escalation routes determine whether that handover works when nobody is watching the demo.
Plan for the platform to change
Migration is not hypothetical. OpenAI’s Agent Builder is deprecated and scheduled to close on November 30, 2026. That removes it from my shortlist for a new build and raises a broader question: how much work survives a platform change? Deprecation notice.
MCP standardises tool and data connections; A2A supports communication between agent applications. Neither makes the whole application portable.
I put particular value on keeping test cases and expected outcomes outside a platform’s proprietary tracing format. “Do not send when identity is ambiguous” should remain testable after migration, even if execution is recorded differently. Reusing the policy-lookup tool helps; preserving evidence that the process works matters just as much.
We will carry that scenario through the series, starting with the Copilot Studio build. Tomorrow’s inbox remains the test.
Which step in your process can an agent choose, and who takes over when it fails?
Product references checked on September 15, 2026.