The two meanings of “agent harness” The general meaning is everything around the model that turns a completion API into something that can do a job: the loop, context, tools, memory, permissions, identity, evaluation and telemetry. The specific meaning is AWS AgentCore harness, a managed implementation where you configure the model, instructions, tools and skills, and AWS runs the loop, the sandbox, memory, identity and tracing. One word, two meanings This post is about both, and about the gap between them — because that gap is where agent programmes succeed or fail. THE GENERAL MEANING the agent harness Everything around the model that turns a completion API into something that does a job. EIGHT RESPONSIBILITIES · The loop · Permissions · Context · Identity · Tools · Evaluation · Memory · Telemetry Yours to assemble — from a framework, or by hand. THE SPECIFIC MEANING AgentCore harness AWS’s managed implementation of all of it, generally available since 2026. YOU CONFIGURE model · instructions · tools · skills AWS RUNS the loop · sandbox · memory · identity · tracing Configuration, not code — until it isn’t enough. The model is the engine. The harness is the rest of the car — and a very good engine in a bad car still crashes.

“Harness” has quietly become the most important word in agent engineering, and it now means two things. This post is about both, and about the gap between them, because that gap is where enterprise agent programs succeed or fail.

The general meaning is this: an agent is a model plus everything around it that turns a completion API into something that can do a job. The loop that calls the model, picks a tool, feeds the result back, and decides when to stop. The logic that manages what’s in the context window. The tool definitions and the code that dispatches them. Memory across turns and sessions. Permissions: which tools may be called, when, and who approves. Identity: who the agent is and whom it acts for. Evaluation, so you know whether a change made it better or worse. And telemetry, so you can see any of the above. The model is the engine. The harness is the rest of the car, and a very good engine in a bad car still crashes.

The specific meaning is AWS’s AgentCore harness, which went generally available in June 2026: a managed implementation of all of that, where you configure a model, instructions, tools, and skills, and AWS runs the loop, the sandbox, the memory, the identity, and the tracing.

If you build agents in an enterprise you need a clear picture of the first meaning before you can decide what to do with the second. That’s the order this post takes.

Opinions here are my own and don’t represent my employer. AgentCore details are as of September 2026 and move quickly; check the docs before relying on any specific one.

Why “harness failures” is the right frame

Symptoms blamed on the model that are really harness failures Hallucination, wrong tool choice, failure to stop, following an injected instruction and being unable to tell which — each is caused by context management, tool descriptions, step limits, treating tool results as data, and telemetry respectively. It looks like a model failure Models improve on their own schedule. The harness is the part you control — and the part that actually broke. WHAT IT LOOKS LIKE WHAT GETS BLAMED WHAT ACTUALLY FAILED “It hallucinated” The model Context grew to 80,000 tokens of tool output and the instruction was buried “It picked the wrong tool” The model The tool description was ambiguous “It didn’t stop” The model Nothing capped the number of steps “It did what the page said” The model A tool result carried an instruction and nothing treated it as data “We can’t tell which” — No trace existed So the question is not “which model?” — it is “which harness, and how much of it do we own?”
Every row in the right-hand column is something you can fix. The middle column is not.

When an enterprise agent goes wrong, the instinct is to blame the model: it hallucinated, it picked the wrong tool, it didn’t stop. Look closer and the cause is almost always in the harness. The context had grown to 80,000 tokens of accumulated tool output and the instruction was buried. The tool description was ambiguous. Nothing capped the number of steps. A tool result contained an instruction and nothing treated it as data. No trace existed to tell you which of these it was.

Models improve on their own schedule. The harness is the part you control, and it’s the part that determines whether an agent is safe to run in a regulated environment. So the question for a platform team isn’t “which model?”; it’s “which harness, and how much of it do we own?”

The harness, component by component

Here is the map. For each responsibility: what it is, why it matters in an enterprise, and where it lives on AWS today.

AAAWgmp1bWIAAAAeanVtZGMycGEAEQAQgAAAqgA4m3EDYzJwYQAAABZcanVtYgAAAEdqdW1kYzJtYQARABCAAACqADibcQN1cm46YzJwYTplNmQ3ZTMzYS02MDBkLTQ5YTAtODYyZS1iOGY0OWFiNzM2YmEAAAADl2p1bWIAAAApanVtZGMyYXMAEQAQgAAAqgA4m3EDYzJwYS5hc3NlcnRpb25zAAAAALxqdW1iAAAARGp1bWRjYm9yABEAEIAAAKoAOJtxE2MycGEuaW5ncmVkaWVudC52MwAAAAAYYzJzaCKpHcxRJH3f/ootdfxq7T8AAABwY2JvcqNpZGM6Zm9ybWF0bWltYWdlL3N2Zyt4bWxqaW5zdGFuY2VJRHgseG1wOmlpZDpiNDkyMGQ3MS0yYTA4LTQ4MjYtYjY0ZC1iZTVlYzZhMjVmMmZscmVsYXRpb25zaGlwaHBhcmVudE9mAAAB4mp1bWIAAABBanVtZGNib3IAEQAQgAAAqgA4m3ETYzJwYS5hY3Rpb25zLnYyAAAAABhjMnNoxnCJhuO0upPwfzCxol+DfgAAAZljYm9yomdhY3Rpb25zgqJmYWN0aW9ua2MycGEub3BlbmVkanBhcmFtZXRlcnOha2luZ3JlZGllbnRzgaJjdXJseC1zZWxmI2p1bWJmPWMycGEuYXNzZXJ0aW9ucy9jMnBhLmluZ3JlZGllbnQudjNkaGFzaFggVKkkE6j/vv07J60rXg+atIQ4xFQ/sdBOjEEekl3GXkKkZmFjdGlvbngdY29tLmFudGhyb3BpYy5jbGF1ZGUucHJvdmlkZWRqcGFyYW1ldGVyc6F4H2NvbS5hbnRocm9waWMub3JpZ2luLWNvbmZpZGVuY2VndW5rbm93bmtkZXNjcmlwdGlvbnhmQ2xhdWRlIHByb3ZpZGVkIHRoaXMgZmlsZSBhdCB0aGUgcmVxdWVzdCBvZiBhIHVzZXIgYW5kIG1heSBoYXZlIGNyZWF0ZWQgb3IgbW9kaWZpZWQgdGhlIGZpbGUgY29udGVudHMubXNvZnR3YXJlQWdlbnShZG5hbWVmQ2xhdWRlcmFsbEFjdGlvbnNJbmNsdWRlZPUAAADIanVtYgAAAEBqdW1kY2JvcgARABCAAACqADibcRNjMnBhLmhhc2guZGF0YQAAAAAYYzJzaJCGt34MRihUAfE/1jrtBCEAAACAY2JvcqVjYWxnZnNoYTI1NmNwYWRMAAAAAAAAAAAAAAAAZGhhc2hYIMfFVazRpSIQc6CwZ2qpXdz7spC6Crrf3A4CVQnVWPCQZG5hbWVuanVtYmYgbWFuaWZlc3RqZXhjbHVzaW9uc4GiZXN0YXJ0GQE8Zmxlbmd0aBkeBAAAAj5qdW1iAAAAJ2p1bWRjMmNsABEAEIAAAKoAOJtxA2MycGEuY2xhaW0udjIAAAACD2Nib3KlY2FsZ2ZzaGEyNTZpc2lnbmF0dXJleE1zZWxmI2p1bWJmPS9jMnBhL3VybjpjMnBhOmU2ZDdlMzNhLTYwMGQtNDlhMC04NjJlLWI4ZjQ5YWI3MzZiYS9jMnBhLnNpZ25hdHVyZWppbnN0YW5jZUlEeCx4bXA6aWlkOjkzNGZkZGRkLWExNzQtNDA5OS1iN2M2LTE1ODJmZTczNDQ3ZHJjcmVhdGVkX2Fzc2VydGlvbnODomN1cmx4LXNlbGYjanVtYmY9YzJwYS5hc3NlcnRpb25zL2MycGEuaW5ncmVkaWVudC52M2RoYXNoWCBUqSQTqP++/TsnrSteD5q0hDjEVD+x0E6MQR6SXcZeQqJjdXJseCpzZWxmI2p1bWJmPWMycGEuYXNzZXJ0aW9ucy9jMnBhLmFjdGlvbnMudjJkaGFzaFggsi7a3JLWHv+bvcyQJI4wxVWXdnWx+lSwtfSTXeJHPw2iY3VybHgpc2VsZiNqdW1iZj1jMnBhLmFzc2VydGlvbnMvYzJwYS5oYXNoLmRhdGFkaGFzaFggFrfy3sf4aYSf3mcpOf9YEc1iumQ9E+FtvwUhwz71leZ0Y2xhaW1fZ2VuZXJhdG9yX2luZm+jZG5hbWVvQW50aHJvcGljIEZpbGVzZ3ZlcnNpb25lMS4wLjBrc3BlY1ZlcnNpb25lMi40LjAAABA4anVtYgAAAChqdW1kYzJjcwARABCAAACqADibcQNjMnBhLnNpZ25hdHVyZQAAABAIY2JvctKEWQISogEmGCFZAgowggIGMIIBjaADAgECAhRA5aAK7sI50L64g/oGQgU9Z1UTADAKBggqhkjOPQQDAzBJMRcwFQYDVQQKEw5BbnRocm9waWMsIFBCQzEuMCwGA1UEAxMlQW50aHJvcGljIENvbnRlbnQgQ3JlZGVudGlhbHMgUm9vdCBDQTAeFw0yNjA4MDcxODQzNTZaFw0yODA4MDYxOTQzNTZaMEQxFzAVBgNVBAoTDkFudGhyb3BpYywgUEJDMSkwJwYDVQQDEyBBbnRocm9waWMgQ2xhdWRlIENvbnRlbnQgU2lnbmluZzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJh6CmvLUBgFFNU0vUKlOVtE6djd17L5SuwX0LemFisBM3dkd/3cyjxFA3Qo5S46fX0/ihY0VZ7mfb9KF703t5OjWDBWMA4GA1UdDwEB/wQEAwIHgDAVBgNVHSUEDjAMBgorBgEEAYPoXgIBMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUzlHiBIFOZFsj+OPEz5o+nMHXXMIwCgYIKoZIzj0EAwMDZwAwZAIwMXMdFJ4BetLLVY7ORuE9noqbbAZOZn/aArXyTwFAZfKrPzxF2vPoJNf1+UCdg1XGAjBwX1zd9WGqYkqmL5SFqw1QySjr1zJfpJM9+1rdDwSPLMOPOjKuiXjoU/pUUeG9RwmhY3BhZFkNngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPZYQAiHCZi2EHjiny7CNkokmr6rx8dBXiSZerkv/Dg1SHlamQ3strWgEEn1jeCgfDR/QArt25VLBpaqJ3TjZFa6fco= The agent harness, and which AWS service fills each part The model sits in the centre. Around it, eight harness responsibilities — the loop, context, tools, memory, permissions, identity, evaluation and telemetry — each labelled with the Bedrock or AgentCore component that provides it, or with "yours" where no managed service does. The harness is everything around the model Each box is a responsibility. The small label is who fills it on AWS today. HARNESS Model Bedrock · inference profile + Guardrail The loop Call model, pick tool, feed result back, stop. Strands (yours) · or AgentCore Harness Context What goes in the window; what gets dropped. Yours · prompt caching helps Tools Definition, dispatch, one door for all of them. AgentCore Gateway · MCP Memory Across turns and sessions. Not your corpus. AgentCore Memory Permissions Which tools, when, and who approves. Policy + SCPs + your approval gate Identity Who the agent is, and who it acts for. AgentCore Identity Evaluation Did it get better or worse after the change? AgentCore Evaluations · your test set Telemetry Traces that cannot be turned off. Observability + invocation logging Managed: adopt it, configure it, evidence it Partly or wholly yours: a decision the service does not make for you Guardrails and cost attribution wrap the model call and apply to every harness. The line under a harness is an SCP.

1. The loop

The core cycle: send the conversation to the model, read its response, if it asked for a tool then run it and append the result, repeat until the model says it’s done or a limit is hit. Every agent framework is, at heart, this loop with opinions attached.

Why it matters: the loop is where step limits, retries, and failure handling live. An unbounded loop is an unbounded bill and an unbounded blast radius. In an enterprise the loop must be able to stop on a policy decision, not only on the model’s judgment.

On AWS: yours, via a framework (Strands is the AWS-native one; LangGraph and the Claude Agent SDK also run on AgentCore Runtime), or AWS’s, via AgentCore harness, which owns the loop and doesn’t let you replace it. Its release notes are explicit: “when configuration isn’t enough,” you export to Strands code and run it on Runtime yourself.

2. Context management

Deciding what the model sees on each turn: the system prompt, how much history, which tool results in full and which summarized, when to compact. This is where most cost and most quality problems originate.

Why it matters: context is the cost lever. The routing post covered picking the model; this is the other half. A chat agent whose context grows every turn gets slower, more expensive, and worse, all at once. In a regulated setting context is also a data-classification question: what from a sensitive tool result is allowed to persist into later turns?

On AWS: mostly yours. Prompt caching (5 minute cache by default, refreshed on every hit, with a 1 hour TTL you can opt into) and the 1M-token context windows change the arithmetic but not the responsibility; a platform still needs a policy for truncation, summarization, and what tool output is retained. AgentCore harness manages context for you inside its loop, which is convenient and also means you should know what its policy is before you trust it with a classified workload.

3. Tools

Defining what the agent can call, with a schema and a description the model reads, and dispatching calls to real systems.

Why it matters: this was the subject of the MCP post. Tools are where an agent stops producing text and starts acting, so they need classification (read, reversible write, consequential, open-world), one governed door, and identity propagation.

On AWS: AgentCore Gateway is the door: MCP servers, Lambda, API Gateway, and other runtimes as targets, with rate limits by principal and tool, and cross-account sharing. Tool classification remains yours; Gateway will expose delete_everything with the same ceremony as search.

4. Memory

State that outlives a single turn: within a session, and across sessions for the same user or agent.

Why it matters: memory is what makes an agent feel competent across interactions, and it’s also a retention and classification liability. What is remembered, for how long, and how a user’s data is purged are governance questions before they’re features.

On AWS: AgentCore Memory, with short- and long-term stores, semantic and episodic strategies, namespaces per user or tenant, and direct ingestion. It is not a knowledge base; retrieval over your documents is still Bedrock Knowledge Bases or your own RAG. The harness turns Memory on by default, which is exactly the kind of default to review before production.

5. Permissions

Which tools the agent may call, under what conditions, and which actions require a human.

Why it matters: this is the difference between an agent that can be trusted with a consequential action and one that can only be trusted to draft. The MCP post’s approval gate lives here.

On AWS: layered. AgentCore Policy enforces rules on tool calls at the Gateway, outside the agent’s code (Cedar or natural language, with session-scoped temporal rules that can require an approval before an action, cap how many times it runs, or hold a running total under a budget). The organization policy (SCPs, egress) is the outer wall that makes the Gateway mandatory. The approval gate for consequential actions, a pending record that a human executes, is still yours to design, though Policy is where it’s starting to be expressible.

6. Identity

Who the agent is as a principal, and whom it is acting on behalf of when it calls a downstream system.

Why it matters: an agent running as one powerful service account is a privilege-escalation path. Every action should be attributable to a user, an agent, and a workload, and the downstream system should see the user’s entitlements, not the robot’s.

On AWS: AgentCore Identity: OAuth client-credentials, user-delegated and on-behalf-of token exchange, a consent portal, private IdPs in a VPC, and a credential vault. It moves identity downstream; it doesn’t decide what that identity may do there. Entitlements stay in the target system.

7. Evaluation

Knowing whether the agent got better or worse after a prompt change, a tool-description edit, or a model version bump.

Why it matters: it’s the gap in most enterprise agent programs. Without it, every change is a guess and every model update is a surprise.

On AWS: AgentCore Evaluations, with built-in evaluators for task completion, tool use, response quality and safety, custom evaluators, online evaluation against production traffic, and an optimization suite for A/B tests and regression runs. What “good” means for your use case, the test set and the expected tool sequences, is yours.

8. Telemetry

Traces of every model call and every tool call, joined by a trace ID, with the guardrail assessment on the model spans.

Why it matters: the observability post made the case. A harness without traces is a black box with a “no” button, and trace capture must be enforced rather than encouraged.

On AWS: AgentCore Observability (one-click, per-agent log groups, trajectory views) plus Bedrock model invocation logging at the account level, protected by an SCP so no application team can switch it off.

And wrapping the model itself

Two things sit on the model call regardless of harness: Guardrails (enforced at invocation via SCP, per the guardrails post) and cost attribution (application inference profiles or the Projects API, per the cost post). They’re not harness components, but every harness passes through them, which is why they belong at the organization layer and not inside any one agent.

The managed harness: what it decides for you

What the managed harness fills, and what it decides for you AgentCore fills tools, memory, identity, evaluation and telemetry with the same primitives you would adopt anyway. It also takes over the loop, the context policy and in-agent permissions, which become AWS configuration rather than your code. Three questions decide whether that is acceptable. The managed harness fills every box — two of them differently The green half you would have adopted anyway. The amber half stops being your code. Same primitives either way Adopting these costs you nothing in control · Tools — via Gateway · Memory · Identity · Evaluation · Telemetry Now AWS’s decisions Configuration, where they used to be code you review · The loop — and what stops it · The context policy · Permissions inside the agent The loop cannot be replaced — only exported to Strands. BEFORE ADOPTING IT FOR A CONSEQUENTIAL WORKLOAD, ASK 1 · What is its context policy for tool results holding classified data? 2 · What stops the loop — and can a policy stop it? 3 · Can you show, per action, that the permission check sat outside the model’s reach?
The amber column is the whole decision. The green column is free.

AgentCore harness is, by AWS’s own description, the orchestration layer as a service: “compute, a sandbox, secure tool connections, filesystem, memory, identity, and observability,” with the loop that “calls the model, picks tools, passes results back, manages context, and handles failures.” You configure the model (Bedrock, OpenAI, Gemini, or any LiteLLM-compatible provider, switchable mid-session), instructions, tools via Gateway or MCP, and skills from a catalog. It gives you stateful sessions in isolated microVMs, a filesystem and shell, immutable versions with named endpoints and rollback, a Step Functions state, and automatic tracing.

Read that list against the map above and the shape is clear. The managed harness fills every box, and for the green boxes (tools, memory, identity, evaluation, telemetry) it fills them with the same primitives you’d adopt anyway. The difference is the amber boxes. The loop, the context policy, and the parts of permissions that live inside the agent are now AWS’s decisions, made by configuration rather than code.

For a lot of use cases that’s exactly right. Internal tooling, prototypes, a low-consequence assistant, a first agent for a team that has never built one: the managed harness gets them to production in an afternoon, with observability and identity done properly from day one, which is far better than most hand-built first agents manage.

For consequential workloads in a regulated setting, the question to ask is the one the risk committee will ask: can you evidence what the harness does? Specifically: what is its context policy for tool results that contain classified data; what stops the loop, and can a policy stop it; and can you show, per action, that the permission check happened outside the model’s reach. If those answers are in the docs and match your controls, adopt it. If any is “we’d have to trust the service,” that’s a workload for the hand-built harness, where every one of those decisions is code you can review.

The escape hatch AWS built is telling: export to Strands and run on Runtime. That’s the vendor saying the same thing.

A decision test

When to build your own harness and when to adopt the managed one Build when the agent takes consequential actions, when the context policy is a data-classification control, when you must prove where the permission decision was made, or when the loop needs custom integration. Adopt when the use case is read-mostly, speed matters more than control of the loop, the team is new to agents, or the standard primitives already give the evidence. Either way the controls do not move. A decision test The harness decision is about the loop and the context. It is not about the controls. Build your own · Consequential actions — you need the approval gate and step limits in code · The context policy is a data- classification control · You must prove, per action, where the permission decision was made · The loop needs a custom evaluator or a bespoke stop condition Adopt the managed harness · Read-mostly or reversible-write, with low blast radius · Speed to a governed first version beats control of the loop · The team is new to agents and would hand-build a worse harness · The standard primitives already give you the evidence you need In both cases, the controls do not move tagged inference profile mandatory guardrail tools via Gateway SCP makes them the only doors
Whichever side you land on, the bottom band stays the same.

Build your own harness on a framework when:

  • the agent can take consequential actions and you need the approval gate and step limits in reviewable code;
  • the context policy is a data-classification control, not a convenience;
  • you need to prove, per action, where the permission decision was made;
  • the loop has to integrate with something the managed harness doesn’t (a custom evaluator in the loop, a bespoke stop condition).

Adopt the managed harness when:

  • the use case is read-mostly or reversible-write, with low blast radius;
  • speed to a governed first version matters more than control of the loop;
  • the team is new to agents and would otherwise build a worse harness by hand;
  • the standard primitives (Gateway, Memory, Identity, Observability) already give you the evidence you need.

And in both cases: the model still goes through the tagged inference profile and the mandatory guardrail, the tools still go through Gateway, and the SCP still makes those the only doors. The harness decision is about the loop and the context, not about the controls. The controls don’t move.

Why a platform leader should care about the word

The reason to be precise about “harness” is that it’s where the leadership decisions in an agent program actually live. “Which model” is a procurement question. “Which harness, and how much of it do we own” is an architecture and governance question, and it’s the one that determines whether the platform can say yes to the next use case with evidence, or only with hope.

Get the map right, decide which boxes must be code and which can be configuration, and make that decision once, at the platform level, rather than letting every team discover it on their own. Then the model can be as capable as it wants to be, inside a harness the organization actually understands.