Elizabeth Fuentes Leone (Eli) hears a recurring question from developers: why learn agent architecture when a coding assistant can build the agent for you?
Her concern is practical. The generated application can produce an answer while the person running it has little understanding of how it reached that answer, or how many tokens it consumed along the way. Getting working code leaves plenty of decisions to examine.
When Shubham Londhe and I hosted Eli, an AI engineer and developer advocate at AWS, on Vibe Check, she showed how quickly a harness could come together with Amazon Bedrock AgentCore from a single command. The configuration fit on one screen: a model provider, a model ID, tools, skills, and a memory resource.
Eli’s harness configuration selects the model provider, model ID, tools, skills, and memory.
That small file selected parts of a much larger system. Understanding those parts gives you a way to specify what you need, review what an assistant generates, and investigate what happens when the application runs.
The architectural decisions are still there, even when an assistant writes the code.
What the model receives and what it can do#
Eli’s diagram makes the agent loop easy to follow. The application supplies a system prompt and user input to a model. The model can select a tool, receive its result, and continue working until it produces an output.
The agent loop brings together the model, system prompt, and tools.
Each connection in that diagram is something you can inspect. The application determines which information reaches the model and which tools are available. A tool’s result becomes information the model can use in its next decision. Giving the agent another tool changes the work it can attempt and the systems it can interact with.
The harness includes the code and infrastructure supporting that loop. In Eli’s demo, the loop itself was TypeScript code built on the Strands Agents framework, generated by the same command that created the configuration. The harness around it included an execution environment, memory, access to tools, and observability. The deployment also created the IAM roles and policies needed for the application’s AWS resources.
In the configuration Eli opened, the tools and skills arrays were empty. Filling those in means deciding which capabilities the application should have, how the model learns about them, and which permissions they require. Those choices give a coding assistant the requirements for the next part of the implementation.
“Add memory” leaves a lot unspecified#
In Eli’s demo, deploying the harness also created a memory resource. What that resource stores, and how the agent uses it, depends on the behavior you’re building.
Continue a conversation#
Eli invoked her agent with a session ID and an actor ID, then introduced herself. The agent replied to Eli, and the AgentCore CLI returned the session ID for continuing the interaction.
The invocation supplies an actor ID and a session ID, then returns the session ID for continuing the conversation.
The session ID groups the conversation. Within a session, the runtime keeps the conversation without a separate memory resource anywhere from 15 min to 8 hours. The actor ID identifies whose information the application is working with. Those identifiers give the application a way to associate interactions with the right conversation and user.
Carry useful information into another session#
Eli also explained how long-term memory could let the agent retrieve information about the same user in a later session. The memory resource in her demo had several strategies for extracting and organizing information:
- Episodic memory for past experiences.
- Semantic memory for facts.
- Summarization for condensed conversation information.
- User preferences for personalization.
The demo’s memory resource has separate episodic, semantic, summarization, and user-preference strategies.
Long-term memory also isn’t instant. Each strategy runs its own model prompt to extract information into a vector store, so Eli had to wait 2 or 3 minutes before a new session would recognize her. Those extraction calls consume tokens too.
Choosing among those behaviors changes what the application retains and retrieves. A conversation history, a summary, and a remembered preference give the model different information to work with. The generated code needs to retrieve the right kind of memory at the right point in the loop, and you need to know which kind it’s using.
There is another kind of information to account for once the agent starts doing work: which operations have completed, what they returned, and what remains unfinished. Temporal’s agent memory and state guide explains how that execution state relates to conversation context and long-term memory.
Progress needs its own recovery mechanism#
Shubham brought questions from developers he had met at MCP events in Bangalore and Mumbai. He described the harness as a body for the model’s brain: the parts that let it remember, act and reach other systems. The developers were building applications with more moving parts and asking how to provide durability, reliability, and observability when those parts could fail.
That concern follows directly from the agent loop. A model call takes time and consumes tokens. A tool can change something in another system. If the process stops after either operation, restarting the application creates a recovery problem: it needs to establish what has already happened before continuing the task.
With Temporal, the orchestration runs as a Workflow, and operations such as model calls and tool invocations can run as Activities. Completed Activity results are recorded in Event History. During recovery, a Worker can reconstruct the Workflow’s progress and reuse those results.
The agent can continue making new decisions as it runs. Temporal’s support for dynamic AI agents explains how model outputs can drive that behavior while the orchestration remains recoverable.
Make the recovery boundary explicit#
The unit of recovery depends on how you structure the integration. Putting an entire agent run inside one Activity does not automatically record every model call and tool operation inside it as a separate completion. A retry of that Activity may repeat its internal work.
External actions also need idempotency or a way to check the external system’s state before retrying. A tool request can succeed while its caller loses the response. Recovery has to handle that uncertain outcome safely.
These are concrete requirements to give a coding assistant: which results must be preserved, which operations may be retried, and how to establish whether an external action succeeded.
You can keep the agent framework#
An audience question asked whether using Temporal and AgentCore meant replacing LangGraph or LlamaIndex. The question makes sense when the same vocabulary appears around tools with different jobs.
For the architecture we discussed, the responsibilities include:
- An agent framework, such as Strands Agents (which Eli’s generated harness used), LangGraph, or LlamaIndex, for implementing the agent’s reasoning and tool-use loop.
- AgentCore for a managed execution environment and supporting services such as memory, gateways, and observability.
- Temporal for coordinating work across calls, failures, and waits, with durable execution state.
Eli’s overview of the runtime, memory, storage, and execution facilities available around the agent.
The Temporal and AWS integrations provide several ways to compose those responsibilities. The choice depends on what the application needs to recover and where its orchestration lives.
For example, orchestrating a call to an agent gives you a different recovery boundary from orchestrating the individual operations within its loop. Knowing which behavior you need helps you ask for an integration that implements it.
Give the assistant enough to work with#
When I asked Eli about her development workflow, she described skills shared across Claude and Kiro, along with an AWS MCP server to help keep the assistant working from current information. She was using documentation and architectural knowledge to guide the generated code.
That knowledge also helps when the agent is running. Eli showed the runtime’s observability view and discussed inspecting invocations, traces, resource consumption, and model usage. Those observations give you a way to investigate her original concern about an application that keeps consuming tokens without a clear explanation of its behavior.
AgentCore runtime metrics from the demo, including invocations, errors, throttling, and resource consumption.
Review the generated behavior#
A generated harness gives you something concrete to examine with the assistant:
- Trace the information passed to the model, including conversation history, retrieved memory, and tool results.
- Identify the tools that can change external systems and the permissions they use.
- Find where completed work is recorded and what a retry can repeat.
- Check the metrics and traces available to explain a run’s latency, resource use, and model usage.
For a requirement like preserving a completed model result through a restart, ask the assistant to build a failure test alongside the implementation. Run it locally first, as Eli recommended for any agent, then restart the process and check that the recorded result is reused. An assistant can write the harness. Knowing what’s in it (what the model sees, what the memory keeps, and where completed work is recorded) is what helps make it production-ready.