Quick Start: Workflow Agent on Harness
Config-first builders who want a bounded reasoning step between existing systems without writing an agent loop. If you prefer a code-first path with full Enrich/Act tools in the loop, see the workflow quickstart.
Use an AgentCore Harness when your event pipeline needs a bounded reasoning step declared as configuration rather than code.
Choose this workload when
- Your event pipeline needs an LLM triage or classification step between existing systems
- The reasoning step is declarative — no custom local tool code in the agent loop
- You want execution caps (iterations, timeout) as configuration rather than code
- Actions run downstream of the harness verdict, not inside the agent loop
Start with the canonical tutorial
Deploy a managed agent loop using configuration only — no agent code. Covers project creation, harness configuration, deployment, and invocation.
Why it fits
Harness fits when the reasoning step is bounded and declarative. The upstream event source triggers the harness, the harness classifies or triages the event, and downstream automation (Step Functions, Lambda) acts on the verdict. Execution limits — a core workflow concern — become config fields (maxIterations, timeoutSeconds) instead of code you maintain.
Choose an alternative when
- You need event sources, durable state, or action execution beyond Harness scope — Workflow automation samples
Safety and production boundary
Action risk: Harness is sandbox-scoped; workflow samples carry their documented risk
A Harness deployment classifies and emits structured verdicts — it does not execute actions itself. Workflow automation samples that include tool-calling may read data, invoke APIs, or mutate state depending on their configuration. Review each sample's Action_Risk disclosure before connecting to production event sources or systems.
This sample creates a working prototype. It is not production-ready. Before routing real users or production data, complete the Production Readiness checklist.
Harness vs. Runtime for workflow agents
The Runtime quickstart implements the full Trigger → Enrich → Reason → Act → Emit loop in code, with Python tool functions for the Enrich and Act phases. An AgentCore Harness is a managed agent loop declared as configuration — a natural fit when your pipeline needs a bounded reasoning step between systems that already exist:
① TRIGGER → EventBridge/SQS delivers the event to a Lambda function that invokes the harness
② REASON → Harness classifies and emits a structured verdict ← this page
③ ACT → Downstream automation executes the verdict
If your orchestration layer is already AWS Step Functions, you don't need the Lambda bridge shown above: Step Functions has a native integration with the managed Harness, so a state machine can declare and invoke a harness directly as a reasoning step, with the model, tools, and behavior specified as state machine configuration. This supports parallel and sequential agent steps within one workflow, with a human-approval state before critical actions, and full audit trail in the execution history (agent input, output, token usage, duration, and links to turn-level CloudWatch detail).
Two constraints to plan around: the InvokeHarness Task state has a hard 15-minute execution limit regardless of the harness's own timeoutSeconds (the harness keeps running past that point toward its own timeout, but the Task state itself has already timed out), and the response includes only the final assistant message as Converse-shaped JSON — earlier turns, tool-use blocks, and reasoning blocks are not included in the output. See the Step Functions AgentCore integration for the full list of limitations.
When execution limits are config, not code
Execution limits — a core workflow concern — become config fields instead of hand-written guards:
| Concern | Runtime (code) | Harness (config) |
|---|---|---|
| Agent loop | You write it in main.py | Managed agent loop |
| Iteration/time caps | You implement them | maxIterations, timeoutSeconds in harness.json |
| Tools | Local Python functions | Declared config: gateway, MCP, browser, code interpreter |
Choose the harness when the reasoning step is declarative and actions run downstream. Choose Runtime when Enrich/Act require custom local tool code in the same loop. See the AWS harness vs. Runtime comparison for the full grid.
Workflow-specific context
The Harness Getting Started tutorial covers project creation, configuration, deployment, and invocation. The sections below cover what matters specifically for workflow workloads:
- Decision criteria — when a config-only reasoning step is enough vs. when you need the full Runtime with local tools.
- Execution-limit mapping — how
maxIterationsandtimeoutSecondsreplace the runaway-loop and timeout guards you would otherwise code by hand. - Event-pipeline positioning — a harness sits at the Reason step; it does not own Trigger or Act. Downstream systems (Step Functions, Lambda) execute the verdict.
- Production boundary — Harness creates a working prototype. Real event-driven pipelines need dead-letter handling, schema validation, and policy enforcement before acting on verdicts. See the Production Readiness checklist.
When to switch to the workflow samples
The Harness path covers bounded reasoning with no local tools. Switch to a workflow automation sample when you need:
- Event sources — wiring EventBridge rules, SQS queues, or SNS subscriptions to trigger the agent directly.
- Durable state — maintaining context across multiple events or long-running workflows.
- Action execution in the agent loop — calling tools that read services, create tickets, or notify on-call as part of the same reasoning pass.
Workflow samples carry their own documented risk profiles. Review each sample's Action_Risk disclosure and apply bounded autonomy policies before connecting to production systems.
Everything produced by the samples on this page is a prototype until you have applied the controls in Preparing for production. Do not use a prototype endpoint to serve real user traffic.