August 9, 2026

Harness, Runtime, and Managed Knowledge Base: Three Layers Everyone Keeps Treating as Three Options

Golden Jacket Field Notes, Week 18

By Erick Mancz

14 min read

Golden Jacket Field Notes, Week 18

I owe you two weeks. I was on vacation, and for once I actually went. Laptop stayed in the bag, phone stayed face down, and by day three I had stopped reaching for it every time I sat still. If you have ever tried to explain to yourself why checking CloudWatch on a beach is "just five minutes," you know how long day three takes to arrive.

I came back on a Monday, opened the AgentCore documentation to write something small, and found that the platform had rearranged itself while I was gone. Harness generally available. Managed Knowledge Base wired into the agent story. A comparison page that answers a question I had been answering badly in architecture reviews for months. So the small article died, and this one happened instead. Two weeks late, and I think worth the wait.

The problem

The same conversation has now happened in enough architecture reviews that I stopped treating it as coincidence.

A team has an agent working. Not a demo. A real one, in front of real users, with a real orchestration loop somebody wrote by hand and somebody else is now afraid to touch. They hear that AgentCore harness went generally available and they ask the obvious question: should we move to harness, or stay on Runtime?

Then the room does what rooms do. Someone says harness is the managed one, which means less control, which means it is probably for prototypes. Someone else says Runtime is the raw one, which means more work, which means it is probably the mature choice. Both statements sound reasonable to everyone present. Both are wrong, and they are wrong in the same way, because they assume the two things sit side by side and compete for the same slot in the architecture.

Then a third person asks where Bedrock Managed Knowledge Base fits into that decision, and the room goes quiet. The honest answer is that it does not fit into that decision at all, because it belongs to a different axis entirely, and nobody in the room has the vocabulary to say so cleanly without sounding like they are dodging.

I have watched teams burn an entire planning cycle on this question. I watched one team decide to stay on their hand written loop specifically because harness "felt like a step backwards in maturity," and then spend the following quarter reimplementing per user memory scoping that harness exposes as a single configuration field. That is what a missing mental model costs. Not points in a design doc. A quarter of engineering time, gone, rebuilding something that was already sitting there.

Why this matters beyond the specific case

Zoom out and this stops being an AgentCore story. It becomes the story of what happens every time a cloud provider ships a managed layer on top of an existing primitive and gives it a name that sounds like a sibling instead of a floor above.

We have all lived through this before. ECS versus Fargate got argued as a choice for roughly two years before the industry internalized that Fargate is a launch type sitting inside ECS, not a competing service. Lambda versus containers became a religious war before it settled into a boring workload question. RDS versus Aurora. EKS versus EKS Auto Mode. The pattern repeats with such regularity that you can almost predict the confusion from the launch announcement. Marketing names a layer, the industry hears an alternative, and eighteen months of bad comparison blog posts follow.

The reason it matters more in the agentic stack is that the cost of guessing wrong runs deeper than usual. Pick the wrong compute abstraction and you migrate a workload, which is annoying and finite. Pick the wrong agent abstraction and you also pick a team shape, a hiring plan, and six months of roadmap, because "we own the orchestration loop" is an organizational commitment long before it is a technical one. Someone has to carry that pager forever. Someone has to be awake at three in the morning when the context window truncation logic does something creative in production.

There is a second order effect I think is badly underrated. When a team believes harness and Runtime are alternatives, they benchmark them against each other, which produces a spreadsheet full of numbers that answer nothing. When the same team understands that harness runs inside Runtime, they stop benchmarking entirely and start asking the only question that actually decides the architecture: is my agent a loop, or is it something else? That question takes ten minutes and a whiteboard. The spreadsheet takes three weeks and tells you nothing you can act on.

Technical deep dive

The three layers, named properly

Every agent has an orchestration loop. Something calls the model, reads the response, decides whether a tool should be invoked, invokes it, feeds the result back, manages the context window as it grows, and decides when to stop. That loop is the agent. Everything else around it is plumbing.

The loop cannot run on ambition, though. It needs compute, a sandbox that isolates one user's session from another, a filesystem, secure outbound connections to tools, an identity model, and observability good enough that you can explain a bad answer three weeks later in front of an auditor who has never heard of a token. That is the infrastructure sitting underneath the loop.

AgentCore Runtime is the infrastructure layer. Serverless hosting for agents. You write the loop yourself, in whatever framework you like, wrap it with the BedrockAgentCoreApp entrypoint, containerize it for ARM64, push it to Amazon ECR (Elastic Container Registry), and deploy. Runtime provides session isolation, scaling, inbound authentication gating, VPC (Virtual Private Cloud) networking, versioning and endpoints, and observability. The one thing it leaves entirely to you is the loop. The loop is yours, and so is every consequence of it, forever.

AgentCore harness is the orchestration layer, managed. It runs on top of Runtime and hands you the loop already built, powered by Strands Agents. Instead of writing orchestration code, you declare what the agent is: model, system prompt, tools, memory strategy, skills, execution limits. Two API calls get you a deployed agent, CreateHarness and InvokeHarness. Changing the model becomes a configuration change instead of a redeploy. Adding a browser tool becomes a one line reference instead of an integration project.

Here is the detail that resolves most of the confusion in one sentence: AWS CloudTrail records harness operations under AWS::BedrockAgentCore::Runtime. Harness lives inside Runtime. Once you see that, the sibling framing collapses on its own.

Bedrock Managed Knowledge Base is the knowledge layer. This one is not an execution model at all. It answers a completely different question, which is where the agent gets its facts. Classic Bedrock Knowledge Bases asked you to assemble the RAG (Retrieval-Augmented Generation) pipeline yourself: pick a vector store, pick an embedding model, tune chunking, add a reranker, then own all four of those decisions for the life of the workload. Managed Knowledge Base collapses that into a single primitive with defaults chosen for you, native connectors for Amazon S3, SharePoint, Confluence, Google Drive, OneDrive, and a web crawler, and smart parsing that reads document structure instead of slicing blindly at a fixed token count.

Runtime is where it runs. Harness is who writes the loop. Managed Knowledge Base is what it knows.

Where the harness versus Runtime line actually falls

The AWS comparison documentation is unusually honest here, and if you read only one page from this entire article, read that one. It draws the line at exactly four capabilities that harness does not support:

Choice of agent framework. Bidirectional streaming. Non agent loop patterns such as graph or workflow style execution. Hooks.

That list is the whole decision. Everything else in the comparison grid, and it is a long grid, shows both harness and Runtime supporting the feature. What changes is the cost of getting it. Harness supports it with no code. Runtime supports it once you write and maintain the implementation yourself.

Look at what falls into that category: short term and long term memory, Gateway, Browser, Code Interpreter, remote MCP (Model Context Protocol) servers, per user memory scoping by actor ID, context window truncation, outbound identity through the token vault, streaming responses, execution limits such as max iterations, timeouts, and token ceilings. Every one of those is a configuration field in harness. Every one is a code commitment in Runtime, with tests, with a maintainer, with a migration path when the SDK moves.

A smaller set behaves identically in both, because those capabilities belong to Runtime and harness simply inherits them: session isolation, VPC networking, environment variables, versioning and endpoints, inbound auth via IAM (Identity and Access Management) SigV4 or OAuth, and the filesystem options, which cover service managed session storage, Amazon EFS (Elastic File System) access points, and S3 Files access points.

So the honest framing goes like this. Harness is strictly more convenient for everything both layers can do. Runtime remains the only option for four specific architectural patterns. If your agent is a loop, harness. If your agent is a graph, Runtime. If you need to intercept the loop mid flight, Runtime. If your team has real institutional investment in LangGraph or CrewAI that you are unwilling to write off, Runtime.

The exit path, which changes the risk calculation

AWS supports exporting a harness configuration to Strands based code that you then run on AgentCore Runtime. Their own framing calls the graduation a config to code translation rather than an architecture switch.

That detail deserves more attention than it has received, because it rewrites the standard objection to managed abstractions. The usual fear is lock in: if I outgrow this, I rebuild from zero. Here, when you outgrow it, the knowledge base stays where it is, the Gateway stays where it is, the Memory resource stays where it is, the endpoints stay where they are. One layer changes hands. Everything else keeps running.

I will say plainly that I have not personally run a large harness to Runtime export in production yet, so treat my confidence in the smoothness of that path as inference from documented behavior rather than scar tissue. The architectural property underneath it, that only one layer has to move, is structural and does not depend on how polished the export tooling turns out to be.

Where Managed Knowledge Base actually plugs in

This is the part that trips people, and it explains why the third person in the meeting goes quiet.

Managed Knowledge Base is not exposed as a harness configuration field the way memory and skills are. The documented integration path runs through AgentCore Gateway. You register the knowledge base as a Gateway target, and Gateway exposes it to the agent as two MCP tools: Retrieve for single shot lookups, and AgenticRetrieveStream for multi hop retrieval that plans sub queries, runs them in parallel, evaluates whether it has enough, and iterates up to five rounds by default through maxAgentIteration.

Because Gateway speaks MCP, the same knowledge base is consumable by a harness agent, by a Runtime agent running Strands, and by a Runtime agent running LangChain, with zero change to the knowledge layer. Knowledge base IDs stay hidden behind the Gateway, so the agent discovers tools by name and never learns what infrastructure sits behind them.

That decoupling is the entire point. It is why the knowledge decision is genuinely orthogonal to the execution decision, and why collapsing all three into a single choice produces architecture you regret.

The access control model, which is what actually gets deals signed

Managed Knowledge Base applies access control in two passes. Native connectors sync ACLs (Access Control Lists) during ingestion, so unauthorized documents never enter the retrieval index in the first place. Then, at query time, permissions get re checked against the authoritative source rather than a cached mapping, and the pre filtered documents stay transient for the life of the API call, never exposed to the model or to the user.

If you have ever sat in a security review and been asked why your RAG system might surface a document belonging to someone whose access was revoked last Tuesday, you know exactly what that second pass is worth. In regulated environments it frequently decides whether the project ships at all.

The reference shape

Managed Knowledge Base behind an AgentCore Gateway, consumed as MCP tools by a harness agent running on AgentCore Runtime, with managed memory, skills pulled from Git or S3 or the AWS curated catalog, named endpoints for rollout control, and the whole thing invocable as a first class state in AWS Step Functions when it needs to participate in a larger deterministic workflow.

Build the knowledge base first. It is the slowest thing to get right and the least likely to change later. Register the Gateway target second. Create the harness third. Set up named endpoints before you have users, rather than during your first incident.

What the official documentation does not tell you

The bill arrives under Runtime. There is no harness specific fee, so you pay for the primitives you consume. That sounds simple right up until FinOps opens Cost Explorer and finds AgentCore Runtime charges for a workload that nobody on the team ever deployed to Runtime. Harness runs inside Runtime, CloudTrail already told you so, and the billing follows the same logic. Warn your FinOps team before they find it during a monthly review and open a ticket.

Gateway knowledge base targets only work with managed knowledge bases. If you already run a classic knowledge base with a hand tuned vector store and a reranker you are proud of, moving to this pattern is a migration with its own project plan. Scope it accordingly. Equally easy to miss, and buried in the same page: only IAM outbound authentication is supported for those targets.

The most common silent failure is a missing permission. The Gateway service role needs bedrock:Retrieve on the knowledge base ARN. Without it, the target registers cleanly, the tool shows up in discovery, and retrieval simply returns nothing useful. This belongs to the same family of bug as the Lambda Function URL double permission trap I documented in the Week 02 companion repo, and it fails the same way: everything looks configured, nothing works, and the error message points somewhere unhelpful.

"Harness has no hooks" deserves more weight than the grid gives it. It sits in a table row next to bidirectional streaming, which makes it read like a niche capability for people doing exotic things. In regulated workloads it is frequently the deciding constraint. If your compliance posture requires intercepting every model call before it is issued, to log it, gate it, or redact it, that is a hooks requirement, and hooks are Runtime only. I would move this to the top of the four item list, because it converts more enterprise workloads to Runtime than the other three combined.

The whiteboard test beats the feature list. Sketch your agent. If it comes out as a cycle, harness fits comfortably. If it comes out as a flowchart with conditional branches and parallel fan out, harness will fight you the entire way. When that happens you have two good options and one bad one. Go to Runtime, or decompose the graph into Step Functions with harness invocations at the nodes. The bad option is bending a graph into a loop through prompt engineering, which demos beautifully and falls apart around month three, usually in front of someone important.

Bring your own container still means ARM64. Custom environments are supported in both harness and Runtime, and the Graviton requirement survives the move to managed orchestration. Build with --platform linux/arm64 or watch the deploy fail in a way that takes an hour to diagnose the first time.

Evaluation is the part that convinces your skeptics. AgentCore now ships production insights that surface silent behavioral failures, the ones that produce a wrong answer and no error signal at all, plus intent clustering, trajectory analysis, recommendations for prompt and tool description changes grounded in observed behavior, batch evaluation against datasets, and A/B testing on live production traffic with statistical significance reported per session. In business case conversations this section consistently moves people more than anything about orchestration, because it converts "the agent seems better now" into a number somebody can defend. AWS buried it inside a features announcement when it is really the governance story.

The seniority trap is real and it is expensive. Choosing Runtime because it feels more serious is how a strong team spends a quarter rebuilding session management and arrives at production with a worse version of something AWS hands out as a configuration field. Managed does not mean junior in this stack. Let the constraint that pushes you off harness be one you can state in a single sentence to a skeptical architect.

The bigger picture

Step back from AgentCore for a moment, because the layering story here reaches well past AWS.

Two years ago, a team that had built a solid agent loop, with clean session handling, sane context truncation, and decent tracing, owned something genuinely valuable. That work was hard, it was scarce, and it was defensible in a design review. Today the same team owns something a cloud provider gives away as a configuration field, and the months they spent building it are sunk. That is uncomfortable to say out loud and I believe it is the correct read. Orchestration is commoditizing, and it is commoditizing faster than most roadmaps assumed.

What that means practically is that differentiation moved up the stack. It now lives in three places: the knowledge you feed the agent, the tools you expose to it, and the evaluation discipline you apply to it. Notice that all three are organizational assets rather than code. Your knowledge advantage comes from having documentation worth retrieving and permissions modeled correctly, which represents a decade of information governance rather than a sprint. Your tool advantage comes from having APIs that are safe to hand to a model, which is a question about engineering culture. Your evaluation advantage comes from actually measuring agent behavior in production instead of asserting that it improved, and that one is the hardest of the three, because it requires admitting the times when it did not.

None of those three can be bought as a managed service. That is precisely why the value went there.

A second thread deserves naming. The convergence toward a layered agent platform, covering hosting, orchestration, knowledge, identity, tools, and evaluation, is happening across every major vendor at roughly the same time, with roughly the same decomposition, and the seam between layers keeps landing on MCP. That is what happens when an industry finally agrees on the boundaries of a problem. For practitioners it carries good news of a specific kind: skills at the boundary transfer between platforms. Understanding how a knowledge layer should expose itself to an execution layer is portable. Deep fluency in one vendor's orchestration SDK is becoming much less so.

Which brings me to the career implication, and I will state it plainly because I believe it. If your value proposition is that you can write an agent loop, the ground is moving under you right now. If your value proposition is that you can decide which layer a problem belongs to, and then defend that decision in front of a security review and a CFO in the same afternoon, you are fine. That skill has never been automatable and I see no sign of it becoming so.

The teams that thrive over the next two years will be the ones that were honest about which parts of their stack were never differentiating in the first place, handed those parts off without ego, and spent the reclaimed quarters on the parts that were.

Takeaway

Runtime is where it runs. Harness is who writes the loop. Managed Knowledge Base is what it knows. Three layers. Treat them as three competing options and you will architect badly.

Choose Runtime over harness for exactly four reasons: another framework, bidirectional streaming, non loop patterns, hooks. When none of those apply, harness is the correct answer, and writing your own loop becomes an expensive detour dressed up as rigor.

And the knowledge decision never sits on that road at all. It runs through Gateway, and it stays there no matter which execution layer you land on.

One question I keep turning over without a clean answer. When a team outgrows a managed abstraction, do they graduate or do they rebuild? The harness to Strands export says AWS is betting on graduate. What I have seen in the field says most teams rebuild anyway, because the export gives them permission to finally do the thing they had wanted to do six months earlier. If you have run that migration for real, I want to hear which one it turned out to be.

References

About the author

I am an AWS Solutions Architect with more than 10 years in cloud, focused on production ML and GenAI workloads for regulated organizations. I hold every active AWS certification, including the Generative AI Developer Professional as an Early Adopter, the status AWS calls Golden Jacket. I am the sixth Brazilian Golden Jacket holder according to the Awstronauts list, and co-founder of Golden Jackets Brazil.

Golden Jacket Field Notes is a weekly practitioner series. No re:Invent recaps. No tutorials. Field notes from workloads where outages, audit gaps, and cost surprises are not tolerated. The full index lives at golden-jacket-field-notes.

#AWS #AmazonBedrock #AgentCore #AIAgents #GenerativeAI #CloudArchitecture #RAG #MCP #StrandsAgents #GoldenJacket