AI Guardrails: How to Make an AI Agent Prove Its Work

Key takeaways

• When an AI agent says a task is done, that is a claim, not proof. The model works with probabilities and tends to please, so the check has to come from outside the agent.
• You can't make the model deterministic. You can make the checks around it deterministic: a written spec, a checker that didn't do the work, and scripts that decide when checks run.
• Supreme Team, Christoffer Tyko's free set of 53 agent skills, is one worked example. The six guardrails below also work as plain questions for your team or supplier.

When an AI agent tells you a task is done, you have its word for it and nothing more. AI guardrails are the rules and checks around the agent that turn that word into something you can verify.

In the third episode of intelligence.md, the Ninja Partners series on making AI work in small and mid-sized businesses, I talked to Christoffer Tyko of Tyko Tech about exactly this. Chris had worked across several AI coding tools, "a little bit Antigravity, a little bit Codex, a little bit Claude", and kept missing something in each. Above all, a session he started in one tool couldn't come with him to the next. So he built Supreme Team, a free set of 53 skills that puts a fixed way of working around the agent. This article covers what he showed on 22 October 2026 and turns it into questions you can ask whoever builds with AI for you. You can watch the full session on YouTube or listen on Spotify.

Why "done" isn't proof#

An agent's report on its own work is the weakest check you have. Language models are probabilistic: ask the same thing twice and you get two different answers. They also lean towards the answer you want. In Chris's experience, the model was often "more interested in pleasing you than being honest."

Agents are still useful. They just shouldn't mark their own homework, so the question to ask is who checks the work, and against what.

Can you make AI deterministic?#

No, and Chris didn't try. "You cannot make the AI deterministic, but what you can do is you can give it a deterministic tool set around it."

Deterministic means the same input gives the same output every time. A language model can't promise that, while a script that compares the result with a written spec does it on every run. So the guardrails move the checking out of the model and into things that don't change their mind, such as a spec agreed before the work starts and a log the agent didn't write.

What is an agent harness?#

An agent harness is everything around the model that shapes how the agent works: its instructions, the tools it may use, and the checks it has to pass before work moves on.

Chris splits it in two. The application harness is the part the coding tool controls, the memory and rules that live inside the tool itself. "You don't really control that." The user harness is the part you control, and that's where he puts his effort.

Most of the user harness is made of agent skills: written instructions the agent loads for a specific kind of task. Chris compared them to briefing a colleague. "I'm not giving the AI something that it doesn't already know. I'm giving it direction of how I expect something to be done."

Six AI guardrails worth asking for#

Supreme Team builds six guardrails into its skills. You don't need to install it to use them. Each one works as a question for your developers or your supplier.

1. A written spec before the work starts#

In Supreme Team you only talk to one skill, the Admiral. It reads your request and the existing code, then asks questions until the contradictions are gone. Chris took the idea from another open-source skill called Grill Me, and he wants the agent to work out what it can by itself first. "I don't want it to ask me a hundred questions. I only want it to ask me the relevant questions."

The result is a written spec. Every later check compares the work against it. Without one, a review has nothing to measure against, and "looks fine" becomes the standard.

2. A checker that didn't do the work#

The person who built something is the worst person to approve it, and the same goes for agents. Supreme Team splits the work into teams for design, building and code review. The review team includes an adversarial reviewer whose job is to tear the result apart against the spec. Chris named it after Mr. Robot: "a pen test, basically."

3. Scripts, not the agent, decide when the checks run#

One attendee asked exactly this during the session: why not just use skills, without scripts? Chris's answer: "Without the hooks there is no guaranteed way of executing the Python scripts."

Hooks are a layer between the model and the computer it runs on. They fire on fixed events, such as a new request or the agent using a tool, and start the checks. At each review gate a script compares the result with the spec, and the work passes, goes back for fixes, or comes back to you. Hooks only work in coding tools that support them, so it's worth asking which tools your team uses.

4. Effort that matches the task#

A full pipeline for every small change wastes time and money. Supreme Team sorts each request into one of four tiers before anything happens. "If I just want to make a small change, like a button for example," the Admiral looks at the code, decides it's a small change, and runs the short path. According to the walkthrough, a small fix takes five steps, and only the biggest jobs run through all twenty.

5. Logs the agent didn't write#

Every team has to produce a report on what it did, and those reports are what the review gates look at. They are "generated by the Python scripts and the hooks, they are not generated manually by the agent. So that's why they can work as a reliable reference." Each report also has to carry a SHA-256 hash. A hash works like a fingerprint for a file: if anyone changes the report afterwards, the fingerprint no longer matches.

The same records keep the work recoverable. Supreme Team saves each run as a folder in the project, with the spec, drafts, revisions and evidence. If the coding tool crashes, the next session starts from the last saved point. Chris said you can even close Claude halfway through a job and carry on in Codex.

6. After three failed rounds, a person decides#

Human in the loop AI doesn't have to mean a person approving every step. In Supreme Team, you agree the spec at the start, and from then on "you have effectively given over the responsibility to the Admiral." The checks run without you, until something keeps failing. "If he fails on the same step three times, then you become the decision maker."

For most businesses that's a sensible default. A person sets the standard at the start and gets pulled back in when the system can't meet it, without having to read every line.

Supreme Team: one way to build this#

Supreme Team is free and open source on GitHub under the MIT licence. It runs with coding agents such as Claude Code, Codex, GitHub Copilot, Cursor and OpenCode and needs Python 3.13 or newer. The skills it ships with are for building software, but it includes a skill maker for building your own skills for other kinds of work.

Chris built it on top of other open-source skill sets, including Get Shit Done, Superpowers and gstack. "If they didn't exist I wouldn't be able to create this one." His documentation compares them, and he was clear about what that comparison is: "not a comparison of who is better or who is worse", but a picture of what he was missing.

In the live demo, he installed Supreme Team from the instructions in the repository and gave the Admiral a deliberately vague request: create a management skill. The Admiral first looked through the computer on its own and only then asked one question, with three options to choose from.

If you want to see how it all fits together without installing anything, Chris's interactive documentation, Supreme Team: Inside the Harness, walks through it one slide at a time. You can get it with the form below the article.

Questions to ask your team or supplier#

If someone builds software or automations for you with AI agents, these six questions tell you quickly how much of the checking is real:

• What does the agent work against? Is there a written spec before it starts?
• Who checks the result, and did that checker do the work?
• What starts the checks: the agent itself, or something outside it?
• Can I see the logs, and who or what wrote them?
• Does a small fix go through the same process as a new feature?
• At which point does a person decide, and who is that person?

Clear answers don't guarantee good work, but vague ones usually mean the checking still rests on the agent's word.

Where to start#

Start with the questions above and one piece of work your team already hands to an agent. Ask for the spec and the log behind the last result, and see what comes back.

If you'd rather go through your tools and workflows with someone first, that's what our AI Readiness Audit is for: a senior-led look at where AI pays back in your business, where it doesn't, and what it will actually cost. The full session with Chris and the other episodes of intelligence.md are on the series page.

Sources#

• The session: harness, skills, guardrails, demo and quotes - intelligence.md Ep. 03, "Don't take AI's word for it", with Christoffer Tyko, interviewed by Kerstin Dallinger, recorded 22 October 2026, on YouTube and Spotify.
• Supreme Team: skills, hosts, requirements and licence - TykoDev/SupremeTeam on GitHub.
• Tiers, steps and checks as of 19 October 2026 - Supreme Team: Inside the Harness, Christoffer Tyko's interactive documentation.
• Christoffer Tyko - Tyko Tech.