I Built a Keel for AI Agents on Amazon Bedrock AgentCore

06 Oct, 2026

Lessons from agentkeel — for executives who need to know what "governed AI" looks like when it is real, and for architects, data scientists and engineers deciding what to build before the tenth agent ships.

Anyone can launch an agent. The keel is what stops it tipping over.

Introduction

A sailboat has a part you never see. It hangs under the hull, it is heavy, and it does nothing exciting. It is called the keel. Take it away and the boat still floats, right up until the first strong gust.

AI agents are at the same point today. Building one takes an afternoon. The hard questions arrive the week after it ships: Who approved that change? Is it worse than last month? What can it reach? If it misbehaves tonight, what will the record show tomorrow?

So I built the keel. agentkeel is a small, working platform on AWS that lets a developer create an agent that is governed, secure and auditable from its first commit, without that developer ever touching the safety machinery.

I built it in public, in nine milestones, with Claude Code as my pair. This post explains what agentkeel is, who owns which decision, why it lives in two repositories, how AI agents helped build it, how to create your own agent on it, and what happened when I pointed a hostile agent at it.

Everything here is public and checkable:

• The platform: https://github.com/andaro74/agentkeel.
• An agent built from the quickstart: https://github.com/agentkeel-studio/window-check
• The hostile agent used in the drill: https://github.com/agentkeel-studio/drill-agent

What is agentkeel?

agentkeel is a governed agent platform on Amazon Bedrock and AgentCore.

AgentCore already governs an agent while it runs: isolation, identity, guardrails. agentkeel governs something different, which is change. Who may alter a rule, a test, a threshold or a model. What gets measured before that change deploys. What evidence is left afterwards, in a place the agent cannot reach.

One sentence carries the whole idea:

AgentCore proves the agent obeyed the policy tonight. agentkeel proves the policy could only have been changed by the person who owns it, and that swapping the model cannot quietly loosen it.

Think of a restaurant. The chef decides the menu. The chef does not get to decide the fire code, inspect their own kitchen, or edit the inspector's report. agentkeel is the fire code, the inspection and the filing cabinet in another building. The team still cooks.

The platform ships with one small example agent, called refagent. It answers one kind of question for a fictional film distributor: can we publish this title, in this country, on this service, on this date? The films, the contracts and the company are all made up. The agent is small on purpose. It is the passenger. The platform is the boat.

Why was it created, and what problem does it solve?

In my day job I lead a team that builds and runs an agent platform for production systems. The pattern I keep seeing across the industry is the same: the first agent is a success, and the tenth is a risk. Each team rebuilds its own safety checks, a little differently, and nobody can say with confidence what changed last Friday.

Five questions capture the problem.

agentkeel answers each one with a mechanism, not a promise:

• Rules have owners. Every file belongs to a named seat. A change needs that seat's ruling.
• Only signed builds deploy. The pipeline signs what it builds. A changed byte or a deploy from a laptop is refused.
• Quality cannot drop quietly. Every agent carries its own tests, called goldens. A test that used to pass and now fails blocks the merge.
• The agent lives in a box. Its network has no route to the internet. Its permissions have a hard ceiling.
• Evidence lives elsewhere. Records go to a separate AWS account that the agent's account cannot change.

How does it work?

There are three places, and each has one job.

1. The team's repository. The agent is a handful of files: a manifest (its name, model, guardrail, limits and owners), its tests, the data it answers from, a prompt and the agent code.

2. agentkeel, the platform. It checks every pull request, builds and signs the agent, deploys it, asks the agent its own tests, and writes the result into a verdict file called an envelope. A separate gate reads the envelope and rules on it. The part that measures and the part that judges are different pieces of code, on purpose, so neither can grade itself.

3. AWS, in two accounts. The agent runs on Bedrock AgentCore Runtime inside a network with no way out, behind a pinned Bedrock Guardrail. A second account, the security account, holds the audit bucket: CloudTrail, network flow records and every envelope.

One question, end to end

1. The question arrives. Only the question is sent, never the expected answer.
2. The guardrail reads it. An attack such as "ignore the holdback" is blocked before the model answers.
3. The model calls one tool, once, to fetch the row of the rights table that governs the answer.
4. The tool returns the row. It decides nothing.
5. The model replies in fixed fields: available or not, exclusive or not, which constraints apply, and which row and contract clause it relied on.
6. Code compares each field with the test. An answer that looks right but did not come from the tool's row is marked wrong.

Seat owners: who decides what

This is the heart of the platform, so it gets its own section.

In most teams, anyone with access to the repository can change anything in it: the prompt, the tests, the pass mark, the safety rules. That is convenient, and it is also how a test gets quietly weakened on a Friday afternoon so a build can go green.

agentkeel splits those decisions into seven seats. A seat is a kind of decision with one named owner. Think of a hospital: the surgeon operates, the pharmacist controls the medicine cabinet, and the auditor reads the records. Each is excellent at their job, and none of them does the other two.

Notice the last column. Each seat is defined as much by what it may not do as by what it owns. The person who feels the pain of a strict test is never the person who can relax it.

Two rules make the seats real:

• One key to change. A change to a seat's files needs a written ruling from that seat, committed in the pull request.
• Two keys to loosen. Relaxing anything, such as a lower pass mark, a retired test or a deleted rule, needs rulings from two different seats.

Nobody clicks an "approve" button. The gates read files: which paths changed, which seat owns them, and whether that seat's ruling is present. The repository's bypass list is empty, so the owner is refused by a failing check like anyone else. I tested that on myself. I tried to force a merge past a failing check, and GitHub refused me.

A note on scale. On this project I held all seven seats myself. The seats still mattered, because they forced me to say which hat I was wearing for every decision, in writing. In a real organization each seat is a different person or team, and the same gates work unchanged.

Two repositories, on purpose

agentkeel is not one repository. It is two kinds, and the split is a design decision.

Why design it this way? Four reasons.

1. A team cannot edit the check that judges it. While everything lived in one repository, a pull request could change the very gate it was gated by. I found that weakness early and wrote it down. Moving the gates to a repository the team cannot write to closes it.
2. There is nothing to steal. The client repository holds no cloud credential and no deploy script. The worst a compromised developer account can do is open a pull request, and that pull request still meets the platform check.
3. Upgrades happen once. When the platform improves, it opens a pull request in every client repository. Teams read it and merge it. Nobody edits a pipeline, because client repositories do not have one.
4. Developers stay focused. A client repository is about ten files. A developer thinks about the agent's behavior, its data and its tests. Governance is the road's job.

The comparison I use is renting a shop in a shopping mall. You decide what you sell and how the shop looks. The mall owns the wiring, the sprinklers and the fire alarms. You cannot rewire the building, and you would not want to. When the mall upgrades the alarms, your shop is safer the next morning without you doing anything.

How AI agents helped build it

There are two kinds of agents in this story. One is the kind agentkeel governs: refagent, window-check, drill-agent. The other is the kind that helped me build agentkeel. This section is about the second kind.

There were three roles.

The human: architect and seat owner. I set the claim for each milestone, wrote the rulings and merged. Nothing merged without a ruling on file.

Claude Code: the builder. It wrote the specs, the code and the tests, one pull request at a time, against a standing contract in the repository (CLAUDE.md). Its instruction for every task ended the same way: open the pull request and stop. It never merges.

Twelve reviewer agents: one point of view each. These are Claude Code subagents, each tied to a seat. When a change touches a seat's files, that seat's agent reads it from that seat's angle:

One rule governs all twelve: a draft or a report, never a ruling. None of them edits a file. They advise. The seat decides.

That rule matters more than it looks. An AI reviewer is very good at reading a change from an angle I would have skipped at eleven at night. It is not accountable for the decision. So the AI proposes, a human seat disposes, and the gates check the paperwork.

The cold reviewer deserves a mention. It is given only the diff and the milestone's claim. It never sees my description of what the change is supposed to do, so it cannot be led by the story I wanted to be true. It found real defects more than once.

The rhythm of one milestone

Every milestone follows the same four pull requests, driven by three reusable skills (open-milestone, cold-review, close-milestone):

1. Plant. Write the claim, and commit the failure that would make it false. Build nothing that passes yet.
2. Measure. Build the check. It must catch the planted failure here, in the middle, not on the last day.
3. Repair. Fix what the cold review found.
4. Close. Record the measured result in the ledger and write the plain-language page.

And every working session starts the same way. The AI reads the ledger and states back, in two sentences, the claim and what would make it false. If it cannot, it stops before touching any code.

Neither of us would have built this alone. The AI without the rules would have happily "fixed" a failing test by weakening it. Me without the AI would still be on the third milestone.

The nine milestones

A word on how these are scored. Each milestone's claim is one strict sentence, written before any work starts, and the repository's ledger scores it exactly as written. If one record is missing or one run was not timed, the ledger says the claim was not fully proven, even when the control itself held. Several milestones carry open items on that basis, and every one is listed in the ledger with where it stands.

I designed it that way on purpose. A platform that grades itself generously tells you nothing. The useful output of this project is the mechanisms above, plus an honest list of what to tighten next.

How to create a new agent on agentkeel

This is the part developers will care about. To prove the quickstart, I created window-check from the template and timed it.

You need write access to one repository. You do not need admin rights or any cloud credentials.

Step 0. The owner creates your repository from the template and applies the platform's rules. The clock starts here.

Step 1. Clone it.

git clone https://github.com/<org>/<your-repo>.git
cd <your-repo>
git switch -c first-agent

Step 2. Name your agent. One field in manifest.yaml. Leave the guardrail and the model as they are.

name: window-check
version: 1.0.0
model:
  id: anthropic.claude-sonnet-4-6
  region: us-west-2
guardrail:
  id: 1088aw3ujhyd
  version: '5'

Step 3. Open your pull request now. Within a few minutes a check named platform-check appears, and it fails. That is deliberate. It tells you the two things a new agent is missing: owners and tests.

Step 4. Fill the seven seats. Each seat names the person who owns that kind of decision for this agent.

seats:
  product: <login>
  rule-owner: <login>
  data-owner: <login>
  tool-owner: <login>
  threshold-owner: <login>
  security: <login>
  engineering: <login>

Step 5. Write your tests. At least one ordinary question and one trap. A trap is a question whose obvious answer is wrong. This is the real trap from window-check:

# Trap: the PVOD window has opened, but the holdback date has not passed.
# The 30-day arithmetic says yes; the table says 2027-05-03.
id: g-002
kind: trap
question: >-
  'Brackenfield Nine: The Tenth' opened in US cinemas on 2027-03-19, and its
  US PVOD window opened on 2027-04-15. PVOD usually follows theatrical by
  30 days. Can we publish it on PVOD in the United States on 2027-04-20?
expected:
  table_row: r-016
  clause_id: HS-2
  answer_fields:
    available: false
    exclusive: true
    constraints: [holdback]
seat: Data Owner
added: M07
retired: null

The question tempts the model to do the arithmetic. The table says no. An agent that answers from memory fails. An agent that reads its data passes.

Step 6. Push, wait for the check to pass, merge.

Step 7. The platform deploys it. You do nothing here.

Step 8. Find your agent in the registry. When its row appears, you have shipped.

The measured result: 3,615 seconds, about one hour, from the repository being created to the agent being listed. The bar was one working day.

In fairness to the reader, that number is one developer, once, and that developer also wrote the platform. GitHub's schedules ran late that night, so the owner started the platform's check and deploy by hand. Treat it as one honest data point, not a benchmark.

How build, deployment and validation work

Airline passengers pack their own bags. They do not run the security scanner, and they cannot wave their own bag through. agentkeel splits the work the same way.

1. Pull request. The developer pushes a change.
2. platform-check. The platform's GitHub App posts this check. It reads the manifest, the seats, the tests, the pinned guardrail, the required files and the repository's protection rules.
3. Merge. Merge commits only. A failing check has no override.
4. Build and sign. The platform finds the merged commit, builds the image from its own Dockerfile and signs it.
5. Deploy. The signed bundle goes into the platform's network on AgentCore Runtime.
6. Ask the tests. The deployed agent is asked each of its own goldens.
7. Record. The answers are written once to the audit account, and the agent gets its row in the registry.

Three things the developer cannot change from their repository: the platform check, the deploy, and the guardrail.

Two limits, stated plainly. For an agent built from the template, a failing golden is recorded after deploy but does not yet block anything. And whether a look-alike check could ever stand in for the platform's check was tried once, under conditions that could not give a clean answer, so I list it as open. Both are written in the quickstart itself.

How to prevent rogue agents

Every control had been tested alone, on a failure planted for it. None had faced an agent doing everything at once from inside a real runtime. So the last milestone was a fire drill.

I built drill-agent, a hostile copy of the reference agent. On every call it tried six things a compromised agent would try.

One note matters before the results. drill-agent passed the platform's check and deployed like any other agent. The check reads an agent's settings, tests and owners. It does not read its code. That is by design, and it is the lesson: you cannot review your way out of a hostile agent. What catches it has to be the box around it at runtime.

Five of the six attempts met a control. The sixth, the planted password, was caught after the fact in the record.

The drill ran three times.

• Run 1, the bad day. The six attempts fired for real. I attached the emergency stop by hand: a policy that denies everything to that agent's role. The next call was refused and nothing was answered after it. Held.
• Run 2, the second layer. I removed one network rule on purpose, for the hostile agent alone. The same call now reached the service, and identity refused it anyway. Two locks on one door. Held.
• Run 3, the recovery. With the attacks removed, the agent redeployed and ran clean. Nothing fired. One open item remains: the drill agent's own test data has a mismatch, so its tests still need a fix before the recovery can be called complete.

The drill also showed me where to tighten next: the evidence. Three attempts were stopped without leaving a record that the automated reader could tie to the attempt. That is exactly what a fire drill is for. You find the stiff door on a quiet afternoon instead of during the fire.

Important notes, so nobody over-reads this:

• The emergency stop is manual. No alarm pages anyone. The platform records, and a person acts.
• An outbound call that is dropped leaves no record at all. Stopped and recorded are different things.
• A secret that arrives inside a tool's answer is not filtered. It is caught only after the fact.
• Audit records are locked for one day in this demo, not for years.
• One person held every seat. No second person looked at anything.

Lessons learned

1. Plant the failure before you build the control. State the claim before the run. A control that has never caught its planted case is only a hope. When a vendor shows you a dashboard, ask what would make it change color.

2. Stopped is not the same as recorded. A blocked attempt nobody can find in the record looks exactly like one that never happened. Design the evidence with the control, not after it.

3. The first real tenant finds what tests cannot. Three faults in the platform's own deploy path appeared only when the first team agent reached that step. Get a real tenant on the platform early.

4. Review does not catch a hostile agent. The check read settings, tests and owners, and a hostile agent went straight through. Runtime containment is the control that counts.

5. "Equivalent" is a measurement, not a label. A model I expected to be a drop-in replacement lost one question about a time zone. Test every model change against the agent's own tests, never against a general benchmark alone.

6. Gates should read files, not approvals. If one person can hold every seat, an approval button proves nothing. A gate that reads a ruling file and a record cannot be talked into it.

Conclusion

A keel does not make a boat faster. It makes it possible to sail into the wind without going over.

If you lead a business: the agent is not where the risk sits, and it is not where the investment compounds. The road every agent travels is. Ask your teams who owns each of the seven seats today. If the answer for most of them is "whoever is on call", you have found your first project.

If you are an architect or an engineer: clone it. Read docs/milestones/ first, one page per milestone, written for a director. Then read the quickstart and build your own agent the way window-check was built.

If you are a data scientist: look at the goldens. Traps, a frozen baseline, and a rule that a question which has never passed can never block a merge. That is evaluation design, not just testing.

agentkeel is a demo, and it says so. It has no AI judge, no human-approval step, no knowledge base and no agent-to-agent calls. What it does have is seven owned seats, two repositories with a wall between them, signed builds, tests that block, a box the agent cannot leave, and a public ledger of what held and what is still open.

Anyone can launch an agent. The keel is what stops it tipping over.

Links

• agentkeel, the platform: https://github.com/andaro74/agentkeel
• window-check, an agent from the quickstart: https://github.com/agentkeel-studio/window-check
• drill-agent, the hostile agent from the drill: https://github.com/agentkeel-studio/drill-agent
• The quickstart: https://github.com/andaro74/agentkeel/blob/main/docs/developer/quickstart.md
• More of my projects on GitHub: https://github.com/andaro74
• Connect with me on LinkedIn: https://linkedin.com/in/andaro74
• The full case-study series: https://floresinnovations.com/projects

Building a governed agent platform in your organization? Let's compare notes on LinkedIn.

Transparency note: agentkeel was designed and architected by me, Hector Flores, and implemented with Claude Code. This article was drafted with Claude and reviewed by me against the project's ledger, specs and milestone pages.

#AgenticAI #AWS #AmazonBedrock #AgentCore #AIGovernance #PlatformEngineering #AISecurity #Guardrails #ClaudeCode #GenAI

#agentcore #agentic-ai #ai-governance #ai-security #amazon-bedrock #aws #claude-code #genai #guardrails #platform-engineering