No Code, No MCP, No Tools: What AgentCore Harness Did With a Markdown File
What AgentCore Harness Did With a Markdown File
Series: Golden Jacket Field Notes (22 articles)
- …
- 14No Code, No MCP, No Tools: What AgentCore Harness Did With a Markdown File This article
Golden Jacket Field Notes, Week 17
I gave the agent one sentence: find the business opportunities hiding in this dataset. No Model Context Protocol (MCP) server. No tools declared. No orchestration code. Not a single line of Python written by me.
A handful of shell calls later, it came back with the answers.
I want to be precise about what that means, because “the agent did it by itself” is the kind of claim that deserves suspicion. What I configured was a harness in Amazon Bedrock AgentCore, running in US East (N. Virginia), with Claude Haiku 4.5 as the model. I picked the cheapest reasoning-capable model on purpose. If the reasoning holds on Haiku, the reasoning holds. I attached one skill of my own authoring, stored in Amazon Simple Storage Service (Amazon S3), containing the schema of the Amazon Athena views and the business rules the agent had to respect. I attached an AWS Identity and Access Management (IAM) execution role. Then I asked the question and watched.
The agent opened a shell. It listed what it could reach. It ran a query. It read the result. It reasoned about what the result implied, wrote a second query against that, and kept going. Six to nine shell calls per session, depending on how I phrased the question. Nothing broke. It never invented a view name, because I never gave it room to guess.
It worked. That is the least interesting thing about it. What matters is what the run reveals about where the boundary between MCP and skills actually sits, and most of the writing published since the harness went generally available in June puts that boundary in the wrong place.
What I Actually Configured
The harness reduces an agent to two API calls.
CreateHarness defines it. InvokeHarness runs it. Everything between them is configuration: the model it uses, the tools it calls, the skills it accesses, the instructions it follows. AWS assembles the loop and runs it.My configuration was thin to the point of feeling like a mistake.
Model: Claude Haiku 4.5. Skills: one, my own, a directory in S3 with a
SKILL.md file in it. Execution role: one, with read access to Athena, AWS Glue, and the S3 location holding query results. Tools: none declared.That last line is where the run gets misread. I declared no tools. The agent had two anyway.
shell and file_operations are default tools present in every harness session unless you restrict them with allowedTools. Shell executes bash commands. File operations views, creates, and edits files. They arrive whether you ask for them or not.So the honest description of the setup is this: an agent with a bash prompt, an IAM role, and a markdown file explaining the business.
The markdown file is what did the work.
Skills Answer a Different Question Than MCP
Since the harness reached general availability, most of what I have read treats skills as a lighter alternative to MCP. Cheaper plumbing for the same job. That framing will put you in a hole, because the two answer different questions, and the AWS documentation is clear about it even where the commentary is not.
An MCP server answers a question about reach: what can this agent call that does not already exist inside its environment. It is a connectivity layer. You stand up a server, expose tools, the agent speaks a protocol to reach them.
A skill answers a question about competence: given what this agent can already touch, how should it behave. Each skill follows the open AgentSkills.io standard, a
SKILL.md file with YAML frontmatter carrying a name and description, plus markdown instructions and optional scripts/, references/, and assets/ directories.The mechanism matters more than the format. Skills use progressive disclosure. The metadata goes into the system prompt upfront at roughly 100 tokens, and the full instructions load on demand through a tool call, only when the task reaches for them. Set that against the failure I documented in Week 4, where connecting five MCP servers to an IDE degraded the agent by flooding its context with tool descriptions it never used. Skills invert the order. The agent learns that a map exists before it learns what is drawn on it.
My proof of concept never needed MCP because nothing I wanted was outside the walls. Athena was already reachable from the microVM under the execution role. What the agent lacked was knowledge: which views exist, what the columns mean, which business rules constrain a valid answer, and when to stop. Knowledge does not travel over a protocol. It travels in a file.
Here is the classification test I use now, and it has the same shape as the one from Week 12:
Can the capability already be reached from the session under the execution role? You have a knowledge problem. Write a skill.
Does it live outside the trust boundary, need a network hop, or need a credential the role does not hold? You have a connectivity problem. Use MCP or AgentCore Gateway.
Teams reaching for MCP inside their own AWS account are answering the second question when they were asked the first. It works. It also costs them a server, an endpoint, an auth decision, and a context budget they never had to spend.
My Skill Versus the AWS Catalog
I ran the same question twice.
The first run used my skill: a directory in S3 holding a
SKILL.md that described the Athena views, what the columns meant, and the business rules that separate an answer that is valid from an answer that is merely true.The second run swapped in the AWS curated catalog. AWS ships prebuilt skills through the AWS Agent Toolkit, organized hierarchically and selected with glob patterns. The analytics category,
specialized-skills/analytics-skills/*, covers Athena, Glue, QuickSight, and data lake operations. One toggle, no plumbing, no authoring.The results split along a cleaner line than I expected.
My skill returned exactly what I asked for, grounded in the rules. The output was opportunities as the business defines opportunities, not as a query defines rows.
The AWS catalog skill returned analytics that were worth reading. It knew Athena. It moved through Glue metadata competently, shaped reasonable queries, and read the results back with sense. What it never reached was the business. The findings were correct and shallow, because nothing in a curated AWS catalog knows what my organization counts as a lead, a risk, or a number worth escalating to a human.
That is the correct outcome, and I want to be explicit that it is not a complaint. The catalog is competence with the service. It cannot be competence with your business, because AWS has never seen your business. Expecting otherwise is a category error, and it is the same error as expecting an MCP server to teach an agent judgment.
Which points at the real answer, and the documentation supports it: the four skill sources are not exclusive. AWS skills, git, S3, and filesystem paths can coexist in a single payload. The catalog removes the agent’s ignorance of Athena. Your own skill removes its ignorance of you. Those are two different kinds of ignorance and you need both gone.
One honest limit on this comparison. One question, one synthetic dataset, one model, one region. That is a field observation, not a benchmark, and I would not build a procurement argument on it. What I trust from the run is the direction, not the magnitude.
Why the Agent Reaches for the Shell
I assumed the shell behavior came from something underneath, and the documentation confirms it. Every harness session runs in its own isolated Firecracker microVM, backed by AgentCore Runtime, with no shared state and no shared filesystem between sessions. The agent gets a real machine, a real filesystem, and a real shell.
That one design decision explains the entire run.
A microVM with an execution role attached is already inside your AWS account. The AWS Command Line Interface (AWS CLI) and boto3 calls the agent made were not crossing a boundary. They were local calls from a machine that already held credentials. There was nothing to connect, so there was nothing for MCP to do.
I want to stay careful here, because I did not build that environment and I cannot tell you what ships inside it. The documentation promises Python and bash. It says nothing about the AWS CLI or boto3 being preinstalled. What I can tell you is what I observed: I provisioned nothing, and the agent reached Athena from the shell using both.
Watch the shape of the reasoning, because this is the part I did not expect. The agent did not write one query. It opened a shell, looked around, ran something small, read the output, reasoned about what the output implied, then wrote the next query against that finding. Six to nine calls, layered, each conditioned on the one before it. Nobody told it to work that way. The skill told it what was true about the data and what the business accepted as a valid conclusion. The layering was its own.
That is how a competent analyst works. What is new is that I got it out of the cheapest model in the family, on configuration alone.
The Bigger Picture
There is a use for this that has nothing to do with shipping a config-defined agent to production.
In Week 2 I published a companion repository mapping the AWS agentic stack. One of its modules is Terraform for deploying a Strands agent to AgentCore Runtime: an IAM execution role, a CloudWatch log group, a container built for ARM64 because the runtime requires it, pushed to Amazon Elastic Container Registry (Amazon ECR), then wired to a runtime resource. At the time, that was the shortest honest path to a running agent on AWS. It is still correct. It is also now the expensive way to discover whether your agent idea works at all.
The harness moves where you start. You define the agent in configuration, run it against real data, watch the reasoning in the trace, tune the skill, and only then decide whether it earns code. When it does, the harness exports to Strands code that runs on the same platform, the same microVM isolation, the same deployment pipeline. Strands is the export target today, with the Claude Agent SDK listed as coming soon.
The sequence inverts. It used to run: write the agent, containerize it, deploy it, then find out it was the wrong agent. Now it can run: configure the agent, prove it, export it, then containerize the thing you already know works.
The repository I published in Week 2 is not wrong. It is just no longer where I would begin.
What the Documentation Does Not Tell You
- The GA announcement and the developer guide disagree. The What’s New post dated June 17, 2026 says the harness is generally available in every AWS Commercial Region where AgentCore runs. As of this writing, the harness overview page in the developer guide still reads “public preview” and carries a note that deployments across regions are ongoing, currently available in Sydney, Frankfurt, and N. Virginia. Check both before you promise a region to anyone.
- The pricing page is explicit about CPU during idle and silent about memory. It states that I/O wait and idle time are free for CPU when no background process runs. It makes no equivalent statement for memory, and it says billing spans the session from microVM boot through idle periods to termination, charging peak memory consumed up to each second. Meanwhile
idleRuntimeSessionTimeoutdefaults to 900 seconds, so a forty second question can hold a warm microVM for fifteen minutes. I have not measured what that idle tail costs, and I am not going to tell you it is billed when AWS does not say so. What I will tell you is that the gap exists and that it sits on the axis where agent cost actually lives. If you want to close it yourself, measure GB-hours in a Data Export, not dollars in Cost Explorer. At one warm microVM the dollar figure rounds to zero and teaches you nothing. The usage quantity is the only thing that talks. - A runaway agent gets 75 iterations and a full hour by default.
maxIterationsdefaults to 75 andtimeoutSecondsdefaults to 3600.maxLifetimedefaults to 28800 seconds, eight hours. All of them are optional, which means all of them are wide open until you close them. - The base environment promises Python and bash, and nothing else. For git, node, or other runtimes, the documentation tells you to install them at session start or bring a custom container. Anything beyond Python and bash that happens to be there is convenience, not contract.
- Skills fail loud. Every fetch failure kills the invocation with a descriptive error. Skills are never silently skipped. Treat that as a feature, because the alternative is an agent that quietly improvises.
- Git skills need egress. S3 skills do not. A git skill clone must complete within 60 seconds, and if the repository needs internet egress your VPC needs a NAT gateway, the same requirement as remote MCP servers and custom container pulls. S3 skills work through S3 VPC endpoints with no NAT gateway at all. In a private VPC, that difference decides your architecture.
- Invoke-time skills beat create-time skills. Skills passed at invoke time are appended after the ones set on the harness, and when both define a skill with the same name, the invoke-time version wins. Useful for testing. Dangerous if someone forgets.
- Skills are re-fetched when the microVM expires. Within a session they persist on disk. When the VM dies and a new session opens, they are pulled again to guarantee freshness. Your skill source sits on the hot path of every new session.
The Takeaway
MCP is a bridge. A skill is a map. When the destination is already inside your walls, a bridge is not the thing you are missing.
The harness makes that distinction cheap to test, because the microVM arrives with a shell, a filesystem, and your execution role already attached. Everything inside that boundary is a knowledge problem. Everything outside it is a connectivity problem. Most of the MCP servers I watch teams stand up inside their own accounts are answering a question nobody asked them.
The AWS catalog will teach your agent Athena. It will never teach your agent you. That part is a markdown file, and writing it is the work.
I gave Claude Haiku 4.5 a markdown file and an IAM role. It queried Athena in layers, respected the business rules, and never invented a view name. No code. No MCP. No tools.
The model was never the hard part. The map was.
This is part of Golden Jacket Field Notes, a weekly practitioner series on production machine learning, generative AI, and cloud architecture on AWS. Not conference recaps. Not tutorials. Notes from workloads where outages, audit gaps, and cost surprises are not tolerated.
Erick Mancz is an AWS Solutions Architect with more than a decade in cloud, focused on production machine learning and generative AI workloads for regulated organizations. He holds every active AWS certification, the status AWS calls Golden Jacket, and is the sixth Brazilian to earn it. He co-founded Golden Jackets Brazil, the community connecting every Brazilian who holds the jacket.
- Medium: medium.com/@erickmancz
- LinkedIn: linkedin.com/in/erick-mancz
- AWS Builder Center: builder.aws.com/community/@imancz
Opinions expressed here are my own and do not represent the views of my employer or any affiliated organization.
Series: Golden Jacket Field Notes (22 articles)
- …
- 14No Code, No MCP, No Tools: What AgentCore Harness Did With a Markdown File This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article