Magazine2026 Q4Agents & operations
Ovia Inc — Magazine
Artificial Intelligence · Agents · Automation
AWS now lets an existing Step Functions workflow serve as a tool for an AI agent, unchanged and at standard rates. The agent chooses the moment and the input; the state machine keeps the discipline.
Every operations team keeps two kinds of knowledge. The first kind is judgment: reading a situation, deciding that now is the moment to act, and choosing the input. The second kind is procedure: the ordered steps that must run the same way every time, because billing, provisioning, compliance and recovery do not forgive improvisation. Automation history is mostly the story of procedure winning and judgment waiting outside. The announcement AWS made on October 29, 2026 rearranges that relationship without breaking it.
Existing Step Functions workflows, Standard and Express alike, can now serve as-is as tools for AI agents, through Amazon Bedrock AgentCore Gateway over the Model Context Protocol. Nothing in the state machine needs to change. A workflow written last year for a scheduler or an event rule becomes, with the gateway in front of it, something an agent can discover, understand and invoke. Both services charge their standard rates, so the runbook an organisation already pays to run costs the same when an agent starts it.
The capability is available in every Region where AgentCore Gateway is available, with one condition that matters in practice: the gateway and the state machine it exposes share a Region. Latency, data residency and failure domains all stay legible. The estate of workflows accumulated over years becomes a tool library, addressable in the protocol agents already speak.
The surface an agent receives is deliberately small: ten operations. Four handle the life of a workflow itself, starting an execution, starting a synchronous execution, listing executions and describing a state machine. Six handle the life of a run already in motion: describing an execution, stopping one, reading its history, and the three task-token replies, success, failure and heartbeat, that let an outside party answer a waiting workflow. Small surfaces are auditable surfaces. A security review can read ten verbs and know exactly what an agent is allowed to do to the operational estate.
The split between workflow types is equally deliberate. StartSyncExecution, the call that waits for an answer, belongs to Express workflows only, matching their short, request-shaped runs. Inspection of runs in flight and the wait-for-task-token pattern belong to Standard workflows only, matching their long, durable executions. The human callback deserves emphasis: a workflow can pause mid-route and wait for a person, and the answer arrives through the same ten verbs.
“The agent decides when to run a workflow and what input to pass; the workflow runs each step exactly as defined.”
The design draws a bright line. On one side, the agent holds the freedom: whether this situation calls for the workflow at all, which workflow fits, and what input the run should carry. On the other side, the workflow holds the rigidity: once started, each step runs exactly as defined, with the retries, timeouts and error paths defined. Nothing about the execution becomes probabilistic because the decision did. For operations leaders, that line is the whole argument. Auditors do not need to trust a model's mood; the record shows a defined machine ran, and the only judgment call was the invocation.
The reverse direction, shipped in June 2026, completes the loop: a Step Functions step can itself run an AgentCore agent. Now agents call workflows and workflows call agents, each where the other is weak. Procedure lends the agent its memory of how things must be done. The agent lends procedure its reading of situations nobody enumerated in advance.
Because listing executions and reading their history are among the ten operations, the same surface that runs work also reports on it. An agent can answer the questions that fill the first minutes of an incident review: which workflows ran last night, which failed, where each failure stopped, and what the last successful run looked like. On-call reporting stops being a person clicking through consoles at 3 a.m. and becomes a summary assembled from the record itself, with the console still there for anyone who wants to verify it.
Organisations rarely lack automation; organisations lack a current, readable account of what the automation did. When the reader of the record speaks the same protocol as the runner of the record, the account keeps itself: an operations log grounded in execution history rather than recollection.
The practical order of work writes itself. Start with the runbooks that already exist as workflows and hurt the most when they wait for a person to press the button: environment checks, data pipeline kicks, access rotations, the nightly reconciliations. Keep the irreversible steps behind task tokens, so the workflow pauses and a person confirms. Treat each workflow's definition as a contract the agent may invoke but never edit, and let the ten-verb surface be the entire grant until the record justifies more.
The orchestration years behind Ovia, network operations at Beanfield from 2011 to 2013 and systems work at Staywired from 2014 to 2022, taught a durable lesson: the runbook was always the asset. This generation lets an agent hold the library and choose with judgment, while the runbooks stay exactly as written. Freedom at the decision, rigidity at the execution. That is a division of labour operations can sign.