Podcast: Strands Agents with Clare Liguori

InfoQ Podcast; host: Thomas Betts; guest: Clare Liguori (AWS, technical lead, Strands Agents SDK) · podcast · 2026-07-20 source ↗ Reader 🖥️

practical · mixed — An interview that is mostly practical (prescribing how to build and operate production agents) but is organized around a theoretical distinction the guest builds and defends over the course of the conversation: model-driven design vs. workflow-driven design, and later, agent harness vs. agent framework. Argumentative core (a directly stated, evidence-backed thesis about workflows vs. model-driven design) carried by narrative case studies (the mortgage example, the AWS console chatbot's evolution, the network-diagnosis agent).

Structure

Key terms

• model-driven approach Model-Driven Agent Design
  Building an agent from just three choices -- a system prompt, a set of tools, and a model -- and trusting the model's own reasoning and tool-call planning to handle inputs, instead of pre-scripting control flow.
• workflow (pejorative use) AI Workflow Patterns
  Developer-authored control-flow scaffolding (if/for/while statements, micro-agents, predefined branches) layered on top of the model to constrain its behavior -- treated as brittle and a source of downward-spiral maintenance.
• agent harness vs. agent framework
  A framework is essentially a while loop -- cycling through model turns and tool execution until the model yields. A harness is the additional layer (context management, memory, persist-and-resume state, self-tracking tools like task lists) that lets an agent sustain long-running, complex, multi-turn work beyond what a bare loop supports.
• steering hooks
  A Strands-specific layer on top of regular hooks: code or an LLM judge run before a tool call, but with access to 'the ledger' -- the full history of tool calls made so far -- enabling stateful, cross-call constraints that a normal pass/fail hook cannot express.
• the ledger
  The full, ordered history of every tool call made so far within a single agent conversation, exposed to steering hooks so they can check accumulated state (e.g., 'has income verification been called and did it pass') rather than just the current call's inputs.
• procedural memory (informal use)
  Clare's own loose label for storing an agent's successful past tool-call trajectories in a semantic-search database and retrieving similar past trajectories to guide handling of a new, related input.

Propositions

• explicitWorkflow-heavy agent architectures are too brittle to handle real-world unpredictable inputs (e.g. compound questions); the model-driven approach -- system prompt, tools, and a model -- is both easier for developers to adopt and more reliable than heavy scaffolding.conf: high
  supportsThis Week in AI: Rethinking the Agent Harness · p2 — Clare's first-person account of Strands moving away from workflow-heavy design is a concrete case of the 'DAG-based workflows -> harness era' phase transition this proposition asserts at the industry level.
• explicitThe more scaffolding and workflow structure is built around a model, the worse the agent performs -- over-architecting for rare failure cases degrades performance in the common, happy-path cases.conf: high
  extendsAgent Harness Engineering · p1 — Sharpens 'a decent model with a great harness beats a great model with a bad harness' into a directional claim: over-scaffolding doesn't just fail to help a capable model, it actively degrades it.
• explicitIn a case study running hundreds of evaluations, simple system-prompt instructions achieved an 82.5% pass rate -- higher than an explicit workflow-based approach -- while 'steering hooks' (hooks with access to the full tool-call ledger) achieved 100% accuracy.conf: high
  extendsStop Overengineering Your Agent Harness · p1 — Supplies quantified accuracy data (82.5% vs. 100%) for the workflow-vs-agent distinction this proposition draws only conceptually.
• explicitA steering hook differs from a standard pass/fail hook by having access to 'the ledger' -- the full history of tool calls made so far -- enabling stateful constraints (e.g., income verification must precede mortgage approval) that a stateless hook or an instruction alone cannot reliably enforce.conf: high
  supportsThe Anatomy of an Agent Harness · p8 — Steering hooks plus the ledger are a concrete implementation of an architecturally-separate enforcement layer, adding a stateful cross-call mechanism this component list names but doesn't specify.
• explicitAn LLM-as-judge should use a different, and can use a much smaller/cheaper, model than the agent it is judging -- both because a same-model judge tends to agree with itself, and because judging output against a rubric is a simpler task than generating it.conf: high
  supportsAnthropic's Designs Three-Agent Harness Supports Long-Running Full-Stack AI Development · p1 — Gives the practitioner rationale (same-model self-agreement bias) behind the empirical finding that agents overrate their own outputs, and prescribes a fix: judge with a different model.
• explicitEngineers building agents must shift from a deterministic 'the test passed, so it's reliable' mindset to a scientist's mindset -- building representative evaluation datasets and continually assessing whether the agent's output is good.conf: high
• explicitPre-launch evaluation datasets are almost never representative of real production traffic, so evaluation must continue against live traffic (traces, sample inputs, user signals) after launch, not stop once the agent ships.conf: high
  extendsThe Production Gap: 5 Patterns for Building Long-Running AI Agents · p2 — Names a concrete mechanism for the demo-vs-real-workflow production gap (eval sets tuned to imagined 'what is X' queries vs. actual 'how do I' queries) and prescribes continuous live-traffic evaluation as the fix.
• explicitTraditional software engineering discipline -- unit-testing individual tools to high coverage, chaos/red-team testing with unexpected inputs -- remains essential in a model-driven architecture; trusting the model to reason doesn't replace testing the deterministic pieces it calls.conf: high
• explicitThe real payoff of the model-driven approach is that adopting a more capable new model should require changing as little as one line of code (the model identifier) -- which only holds if the team hasn't built heavy custom scaffolding tightly coupled to the current model's specific limitations.conf: high
• explicitAn agent framework is essentially a while loop -- cycling through model calls and tool execution until the model yields; an agent harness is the additional layer (context management, memory, persist-and-resume state, self-tracking tools like task lists) needed to sustain long-running, complex, multi-turn tasks beyond what a bare loop supports.conf: high
  refinesThe Anatomy of an Agent Harness · p1 — Sharpens the broad 'if you're not the model, you're the harness' split into a three-way distinction -- model, thin framework loop, and harness -- defining 'harness' specifically as what enables long-running/complex work, not just 'everything non-model.'
• explicitdevelopedAs models have become capable of longer and more complex reasoning/tool-use chains, Strands's engineering focus has shifted from the reasoning loop itself toward context management, persist-and-resume state, and self-tracking tools -- infrastructure hours-long agentic jobs need that synchronous chat-style agents did not.conf: high
  supportsThe Production Gap: 5 Patterns for Building Long-Running AI Agents · p3 — An independent practitioner account (Strands/AWS) converging on the same prescription -- persist-and-resume state, context management, self-tracking work artifacts -- for hours-long agentic tasks.
  extends ←Multi Agent Collaboration Gets Persistent Compute in Bedrock AgentCore · p10 — Liguori described the Strands harness's focus shifting toward 'sustaining long-running, resumable, self-tracking agentic work.' This article shows the concrete infrastructure (AgentCore runtime instances, explicitly naming Strands as a supported framework) that makes that shift operational without requiring Strands itself to change its packaging model.
• explicitStoring an agent's successful past tool-call trajectories in a semantic-search database and retrieving similar past trajectories for new inputs ('procedural memory') measurably improved reliability on a 15-sequential-tool-call diagnostic agent that could previously only chain roughly 10 calls reliably.conf: high
  extendsThe Production Gap: 5 Patterns for Building Long-Running AI Agents · p8 — Gives a concrete implementation of a distinct long-term memory store (semantic-search database of past successful trajectories) separate from the ledger's single-conversation working memory.
• explicitComfort with discarding previously built, hand-written scaffolding as newer models make it unnecessary is a difficult but necessary engineering habit specific to this domain -- unlike traditional software, where written code tends to persist rather than be actively unwound.conf: high
  supportsStop Overengineering Your Agent Harness · p6 — A first-person description of living through the 'Kirby effect' (harness features expire as models absorb the capability they compensated for), including the emotional cost the essay's framing leaves out.
• explicitThe same one-line model-swap flexibility that lets teams adopt more capable (often more expensive) frontier models also lets them downgrade to much cheaper, sometimes open-weight, locally hostable models for many automation-style tasks without materially losing accuracy -- Clare reports reproducing her steering-hooks case-study results with gpt-oss-120b.conf: high
• implicitThere is an unresolved tension between the 'responsible AI' instinct to constrain agents with explicit, auditable workflow/allowlist logic (Thomas's framing of his own team's platform) and the model-driven finding that such constraints reduce both accuracy and flexibility; evals and steering hooks are offered as a way to gain some determinism without giving up flexibility, but whether they satisfy the same audit/compliance bar that motivates workflow-engine designs is never directly addressed.conf: medium

Arguments

Narratives

• A mortgage-processing agent example: a plain hook can block approving mortgages over a million dollars based on the current call's inputs, but only a steering hook with access to the full ledger can enforce that income verification happened before mortgage approval was attempted -- while still allowing a user to ask 'would I be approved' without submitting.
  → Makes the abstract 'ledger' concept concrete; supports propositions 3 and 4 and argument 2.
• The AWS console chatbot's evolution from a 2023 super-simple prompt pipeline (Claude 2-era) into a full model-driven agent with sub-agents, including a network-troubleshooting sub-agent -- each capability jump driven by a new model generation, with old handwritten scaffolding thrown away each time.
  → Illustrates the model-driven philosophy's real payoff (capability growing with each model generation without a full redesign) and the emotional cost of discarding built infrastructure; supports propositions 9 and 13.
• A network-issue-resolution agent needed roughly 15 sequential API calls to diagnose connectivity problems (e.g., 'why can't I SSH to this EC2 instance'), was reliable only up to about 10 calls, and was fixed by saving successful tool-call sequences to a semantic-search database and retrieving similar past trajectories for related new inputs.
  → Concretizes 'procedural memory' as a distinct, cross-conversation memory mechanism from the single-conversation ledger; supports proposition 12.
• Thomas's anecdote about a company that limited an agent to 25 approved prompts, which then failed and repeatedly claimed it couldn't respond when asked anything outside that list.
  → From the interviewer, but functions as a shared data point both speakers build on: illustrates the mismatch between the responsible-AI instinct to over-constrain and how customers actually use agentic systems ('customers will use your service in ways you never predicted').

Questions addressed

• ✅ How do you build a production-reliable agent without heavy, brittle workflow scaffolding?
  The model-driven approach (system prompt + tools + model), supplemented by evals and hooks for guardrails.
• ✅ How do you know an agent 'works' when you can't rely on deterministic tests?
  Evals -- ideally scoped to tool-call correctness rather than subjective output judgment -- plus LLM-as-judge using a different/smaller model, plus continuous live-traffic evaluation.
• ✅ How do you enforce specific hard behavioral constraints (e.g., ordering of tool calls) without reintroducing brittle workflow logic?
  Steering hooks backed by the full tool-call ledger.
• ✅ What's the difference between an agent framework and an agent harness?
  Framework = the loop mechanics (model call, tool execution, repeat until yield); harness = the additional layer supporting long-running, complex, resumable work.
• ✅ What does a production observability stack for agents need, beyond traditional software observability?
  OpenTelemetry traces treated as the primary signal, because agent 'hops' are internal tool calls; continuous comparison of live traffic against an evolving eval set.
• ⭕ Does the steering-hooks/ledger approach actually satisfy the auditability and governance requirements that motivate 'responsible AI' workflow-engine architectures like Thomas's at Blackbaud, or does it just relocate the governance question to 'trust the check we wrote'?
• ✅ If you were starting Strands over from scratch, what would you design differently?
  Build directly for long-running, complex-task harness capabilities (context management, persist-and-resume, task tracking) from the start, because models weren't capable enough for that when Strands was first built.

Gaps

• incompleteThe 82.5% vs. 100% pass-rate case study is reported without published methodology: what were the 'hundreds of evaluations,' what tasks, and -- notably -- the workflow-based approach's own numeric pass rate is never stated, only that it scored lower than simple instructions. No independent replication is cited.
  Read next: Read against extract-oreilly-rethinking-agent-harness#g2, which flags the same single-case-generalization problem for the broader 'harness > model' thesis; look for a published Strands Evals Kit benchmark or third-party replication of the steering-hooks result.
• incompleteThe ledger (full tool-call history exposed to steering hooks) is described through only one worked example (the mortgage ordering constraint); its scaling costs -- token cost of re-checking a large ledger, latency, and how it interacts with context management or compaction for long-running agents -- are never discussed, an odd omission given the same conversation's later emphasis on context management as a first-class concern for long-running agents.
  Read next: Read Strands's own context-management and compaction documentation, and extract-anatomy-of-an-agent-harness#p5 on context rot, to see whether ledger growth is treated as a context-management problem at all.
• illogicalThomas's opening frame -- his own team's workflow-engine approach as a deliberate responsible-AI/security choice ('if we didn't tell it how to do something, then it couldn't do it') -- is never actually answered on its own terms. Clare reframes the question as one of reliability and accuracy, but never addresses whether steering hooks give the same hard, by-construction guarantee ('the agent literally cannot take this action') that a workflow engine's action-allowlist gives.
  Read next: Read work explicitly comparing capability-based allowlisting vs. runtime-checked guardrails for AI agents, and any Strands documentation on formal action restriction (as distinct from steering-hook checks).
• uninformed'Procedural memory' (storing and semantically retrieving past successful tool-call trajectories) is described as something the team 'kind of hacked together' for one internal agent, with no discussion of its failure modes -- e.g., retrieving a superficially similar but actually wrong past trajectory, or memory drift from accumulating trajectories over time.
  Read next: Read extract-turing-post-5-patterns-long-running-agents#p9 and #p20 on memory drift as a real production failure mode, which this document's procedural-memory technique appears exposed to but never discusses.
• incompleteThe claim that 'the likelihood that a frontier model... does go run wild is in practice very small' is offered as a premise for not over-architecting guardrails, but no quantified rate, no definition of 'run wild,' and no discussion of how that likelihood should change with task stakes (mortgage approval vs. 'what is EC2') are given.
  Read next: Read extract-stop-overengineering-your-agent-harness#g2, which already flags the absence of a cost/economics treatment across the harness-design discourse generally, for the same missing quantification applied to risk rather than cost.

Closes gaps elsewhere

• The Anatomy of an Agent Harness · g5 — Supplies a genuine first-party ablation study -- Clare's own case study comparing workflow, simple instructions, and steering hooks across hundreds of evaluations, with real pass-rate numbers (82.5%, 100%) -- partially answering the gap's call to 'build a minimal harness and ablate' rather than relay vendor-reported figures. Partial: it ablates control-flow techniques, not the eleven named components specifically, and the workflow approach's own numeric score is still not reported.

Related documents

• Stop Overengineering Your Agent Harness
• This Week in AI: Rethinking the Agent Harness
• The Anatomy of an Agent Harness
  Agent Harness Agent Memory Agentic Loop Evals
• Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security
  Agent Harness Agent Memory Agentic Loop Long-Running & Managed Agents
• What is “loop engineering?”
  Agent Harness Agentic Loop Long-Running & Managed Agents AI Workflow Patterns
• 20 Loop Design Patterns Every AI Engineer Should Know
  Agent Memory Agentic Loop Evals
• AI Root Cause Analysis Shifts from Model Reasoning to Context Engineering
  Agent Harness Agentic Loop Evals
• Harness design for long-running application development
  Agent Harness Evals Long-Running & Managed Agents
• Audit your Agent files
  Agent Harness Agent Memory Hooks
• Don't train the model, evolve the harness
  Agent Harness Agentic Loop Evals