I ran the same AI agent two ways on AWS, once as a Harness and once as my own code on Runtime. Both gave the right answer, and the times were close: 1.8 seconds and 2.2 seconds. The real difference is who owns the loop.
Amazon Bedrock AgentCore gives you two ways to run an agent, and they look like two different products. I built one small agent and ran it both ways to see what actually changes. I would start with a Harness, and move to Runtime when the config file cannot express what I need.
With a Harness, you describe the agent in a config file. AWS runs the loop where the model reads a question, calls a tool and answers. With Runtime, you write that loop as code, and AWS hosts it.
One agent, one Gateway, one model
The agent is a CloudOps assistant in my personal AWS lab. You ask whether production is healthy. It calls one tool, a Lambda function behind an AgentCore Gateway, and answers from the result. If the data is missing or older than 10 minutes, it says the health is unknown and says why.
Both versions use the same Gateway, the same Lambda and the same model, Amazon Nova Micro. Only the owner of the loop changes. The Lambda returns synthetic data, so this is a lab, not production monitoring.
What I wrote for each
Harness | Runtime | |
|---|---|---|
Who owns the loop | AWS | Me |
What I wrote | A config file and a system prompt | Python with Strands, plus the same prompt |
What I deployed | The config | A code package |
Tools from the Gateway | Yes | Yes |
Choice of framework | No | Yes |
The Harness took less work. For Runtime I wrote code, packaged it and deployed it. The AgentCore CLI then connected the agent to the Gateway and gave its role permission to call it.
The traces looked almost the same
I asked both agents the same question and read the traces. The Harness took 1.8 seconds and the Runtime agent 2.2 seconds, with 11 spans each. The Harness trace is the one from my earlier post on tracing one question. I ran each once, so read these as a rough picture, not a benchmark.
The detail I liked more is the name. Both traces show invoke_agent Strands Agents. The AWS docs say the Harness loop is powered by Strands Agents, so the engine is the same. What Runtime gives you is control over how it is used.
One bug only my own code gave me
My first Runtime deploy failed. The generated client added a prefix to the Gateway tool name, and the final name was 65 characters. Bedrock allows 64. The failed run shows up in the trace list as an error.
I shortened the prefix to ops and deployed again. The second run worked, and the tool span now reads ops_DeploymentStatusTarget. The Harness never had this problem, because AWS builds the tool names for you. With your own code, small details like this become your job.
When I would move to Runtime
The AWS feature comparison between the two options is pretty clear. There are three things you can only do with Runtime: choose your own agent framework, build graph or workflow style patterns, and use bidirectional streaming. I would consider moving to Runtime if you need any of these.
Custom tools alone are not a reason to switch. A Harness already supports Gateway tools, remote MCP servers, and client side tools. The docs also cover exporting to code, so starting with a Harness does not mean you are locked into it.