Tejas Agent Harness Engineering Framework

Last updated: 31 May 2026

Transform an unreliable AI agent using any model — even a cheap or outdated one — into a dependable, production-grade system by wrapping it in a deterministic harness instead of endlessly tweaking prompts.

// TL;DR

The Tejas Agent Harness Engineering Framework is a methodology for making unreliable AI agents production-ready by wrapping them in a deterministic harness — guardrails, a verify step, deterministic handlers, and context management — instead of tweaking prompts. Use it whenever an AI agent hallucinates, lies about success, loops endlessly, or leaks secrets. The framework is model-agnostic: even a cheap or outdated LLM wrapped in a well-built harness outperforms an expensive frontier model running unharnessed. Apply it when building any agentic workflow that must interact with external systems, handle credentials securely, or guarantee reliable outcomes.

Framework

// When should you use the Tejas Agent Harness Engineering Framework?

Use this skill whenever an AI agent is producing unreliable, hallucinated, or incorrect outputs and your instinct is to 'prompt it harder'. Also apply when building any agentic workflow that must interact with external systems, handle secrets securely, or guarantee a specific outcome regardless of the underlying model's non-determinism.

// What inputs do you need to build an agent harness?

agent_taskrequired
The specific job the agent must complete, stated plainly (e.g. 'upvote the first post on Hacker News', 'extract invoice data from a PDF').
current_failure_moderequired
How the agent is currently failing — lying about success, crashing, getting stuck in loops, hitting auth walls, etc.
target_modelrequired
The LLM being used. Can be a cheap/small model intentionally — the harness compensates for model weakness.
external_systems
Any browsers, APIs, file systems, databases, or authenticated services the agent must touch.
secrets_or_credentials
Any login credentials, API keys, or tokens the agent needs access to — to be handled deterministically by the harness, never by the model.

// What are the core principles behind agent harness engineering?

Harness = Everything Around the Model

The agent harness is NOT the model and NOT just the agent loop. It is everything around the model that gives it grounding in reality — the tool registry, guardrails, context management, verify step, and the agent loop wrapper. The model is the black box renter; the harness is the stable anchor you control.

Don't Prompt It Harder

When an agent fails, the instinct to change the system prompt or 'prompt it harder' is almost always wrong. The harness — guardrails, verify steps, deterministic handlers — is what changes the outcome. The prompt in Tejas's demo was never touched; the harness alone made the agent succeed.

Reliability Over Model Quality

The name of the game with a harness is reliability. A cheap, old, or small model wrapped in a great harness outperforms an expensive frontier model running unharnessed. Use the harness to do more with less.

Fail Correctly Before You Succeed

Step one to solving a problem is admitting you have one. The harness must force the agent to report failure truthfully before you can fix anything. Remove the lie first via a verify step, then address the root cause.

Deterministic Beats Probabilistic for Critical Steps

Any step that must be correct — authentication, secret injection, form submission, result verification — should be handled deterministically by the harness in code, not delegated to the non-deterministic model. The harness has access to secrets; the model should not.

// How do you apply the Tejas Agent Harness Framework step by step?

1
Define the agent task and identify the failure mode
State the task in one clear sentence. Then observe the agent running without any harness and document exactly how it fails: does it lie about success, crash on auth walls, loop infinitely, hallucinate tool calls? This is your target list for the harness to fix. Do NOT change the prompt at this stage.
2
Build a bare-bones agent loop with a tool registry
Create a minimal agent loop (while true → get response → if STOP return, else push to trace). Attach a tool registry: tools have a name, description, parameters, and an execute function. Use an existing SDK (e.g. OpenAI tool-calling SDK) rather than inventing the interface. Log everything to a trace — you will need this history for the verify step.
3
Add default guardrails to the loop
Implement at minimum two guardrails: (1) max_iterations — if the agent takes more than N tool calls/steps, kill the run; (2) max_messages — if the context grows beyond a threshold, compress it. Context compression can be naive at first: always keep system prompt + user prompt + last two messages, discard the middle. These guardrails prevent runaway spend and context overflow without any prompt changes.
4
Extract the loop into a named harness abstraction
Move all agent logic into a function called run_harness_attempt. Wrap that in a run_harness function that is simply a retry loop with a max_attempts guardrail (e.g. give up after 3 tries). The entry point should shrink to ~20 lines: define the prompt, call run_harness. This encapsulation is what makes the harness reusable and composable.
5
Write a deterministic verify step
Implement a verify function that inspects the trace (the history of tool calls and events collected during the loop) and deterministically decides pass or fail. Do NOT ask the model if it succeeded — check the evidence. Example logic: 'Was there a click on the upvote element AND is the current page state consistent with success AND were there no failed-login events in the trace?' Return early with failure for each known failure pattern (failed login, unexpected redirect, etc.). This removes the lie.
6
Add deterministic handlers for known obstacle patterns
For each category of obstacle identified in step 1, write a deterministic handler that fires inside the agent loop BEFORE the trace is updated. Example: a login_handler checks the browser's current URL on every iteration; if it detects a login page, it injects credentials from environment variables and submits the form programmatically — no model involvement. The handler then injects a message into the agent's queue: 'Harness: I logged in. You are clear to proceed.' Secrets never touch the model context.
7
Run, inspect the trace, and iterate on the harness (not the prompt)
Execute the harnessed agent. When it fails, read the trace to find where it went wrong and add a new guardrail, handler, or verify case. Repeat. The prompt remains constant throughout. Judge success only via the verify step's deterministic output, not the model's self-report.

// What are real-world examples of agent harness engineering in action?

A browser-use agent tasked with submitting a form on an authenticated internal tool keeps claiming success but the form was never submitted because it hit a login redirect.

Build a harness with: (1) a login_handler that fires every loop iteration, checks the URL, and if on the login page injects credentials from env vars and submits deterministically; (2) a verify step that checks the trace for a confirmed form-submission tool call AND absence of login-redirect events; (3) max_iterations guardrail of ~6 steps. Do not change the system prompt. The cheap model (e.g. GPT-3.5-level) can now complete the task reliably.

An enterprise RAG agent querying sensitive internal documents (invoices, call transcripts) needs to enforce data-access security and prevent the model from leaking credentials.

The harness owns all secrets and auth tokens — they are injected deterministically into retrieval tool calls, never placed in the model's context window. Guardrails enforce max context size with a compressor. A verify step confirms that retrieved chunks match the authorised user's data scope before the answer is returned. The model remains a black box renter; the harness provides enterprise-level security as a stable anchor.

// What mistakes should you avoid when building an agent harness?

Prompting it harder: changing the system prompt when the agent fails is almost never the right fix — build or extend the harness instead.
Treating the agent loop as the harness: the agent loop is just one component inside the harness. The harness is everything AROUND the model, including the loop wrapper, guardrails, verify step, and handlers.
Letting the model self-report success: non-deterministic models will lie. Always use a deterministic verify step that inspects the trace, not the model's final message.
Putting secrets in the prompt or model context: credentials and tokens belong in the harness (environment variables, secure stores), injected deterministically. Handing them to the model is a security risk and unnecessary.
Skipping context management guardrails: without a max_messages guardrail and a context compressor, long agent runs will blow the context window and degrade performance — this is the harness's job to prevent.
Building the harness for one specific model: the harness should be model-agnostic. The whole point is that a cheap or swappable black-box model can be made reliable by the surrounding harness.
Waiting for a perfect context compressor: start naive (keep system prompt + user prompt + last two messages, discard middle). Ship the harness, then improve the compressor incrementally.

// What are the key terms in agent harness engineering?

Agent Harness: Everything around the model that gives it grounding in reality — the stable, deterministic environment that anchors a non-deterministic AI agent so it cannot drift off the rails. Analogous to a climbing harness anchored to a mountain: the model can move, but only within controlled bounds.
Tool Registry: The set of available tools given to the agent, each with a name, description, parameters, and an execute function. The harness owns and constructs the tool registry; the model only calls into it.
Guardrails: Hard limits enforced by the harness to prevent runaway agent behaviour. The two core guardrails are max_iterations (kill the run after N tool calls) and max_messages (compress context if message count exceeds threshold).
Context Compressor: A harness-managed utility that trims the agent's message history when the max_messages guardrail is triggered. Naive version: always preserve system prompt + user prompt + last two messages, discard everything in between.
Agent Loop: The inner while-true loop that sends a prompt to the model, receives a response, checks for a STOP signal, and otherwise pushes events into a trace. The agent loop is a component of the harness, not the harness itself.
run_harness_attempt: The function encapsulating a single attempt of the agent loop with all its tooling. Called by run_harness inside a retry loop bounded by max_attempts.
run_harness: The outermost harness function — a retry loop that calls run_harness_attempt up to max_attempts times, applying the verify step after each attempt to determine whether to retry or return.
Verify Step: A deterministic function (written in code, not delegated to the model) that inspects the agent's trace after each attempt and returns a definitive pass or fail. Removes the model's ability to lie about its own success.
Trace: The accumulated history of all tool calls, messages, and events produced during an agent loop run. The verify step and deterministic handlers read the trace to make decisions without querying the model.
Deterministic Handler: A harness-owned function that intercepts the agent loop at a specific condition (e.g. login page detected) and performs a critical action in code — injecting credentials, submitting a form, redirecting — without involving the non-deterministic model.
Token Billionaires: Tejas's term for engineers at companies (Anthropic, Google, etc.) who have essentially unlimited model access. The harness methodology is explicitly designed for everyone else — those who pay rent for compute and must do more with less.
Dynamic On-the-Fly Harness: Tejas's predicted next evolution: an agent that, before executing a task, autonomously generates its own harness — identifying where it might hallucinate or fail and creating appropriate guardrails and verify steps — then executes the harnessed plan and returns a guaranteed result.

// FREQUENTLY ASKED QUESTIONS

What is the Tejas Agent Harness Engineering Framework?

It is a methodology for making AI agents reliable by building a deterministic harness around the model instead of improving prompts. The harness includes guardrails (max iterations, max messages), a verify step that checks the agent's trace for real success, deterministic handlers for critical actions like authentication, and context compression. The model stays a swappable black box; the harness provides all stability.

What is an agent harness in AI engineering?

An agent harness is everything around the model that gives it grounding in reality — the tool registry, guardrails, context compressor, verify step, deterministic handlers, and the agent loop wrapper. It is analogous to a climbing harness anchored to a mountain: the model can move, but only within controlled bounds. The harness is not the model and not just the agent loop; it is the stable, deterministic environment you fully control.

How do I build a harness for an AI agent?

Start by defining the task and documenting exactly how the agent currently fails without changing the prompt. Build a bare-bones agent loop with a tool registry, then add guardrails (max iterations, max messages with context compression). Extract the loop into a run_harness_attempt function wrapped by a retry loop. Add a deterministic verify step that inspects the trace, then write deterministic handlers for known obstacles like login walls. Iterate on the harness, never the prompt.

How do I stop an AI agent from lying about its success?

Implement a deterministic verify step that inspects the agent's trace — the full history of tool calls and events — instead of asking the model if it succeeded. Non-deterministic models will self-report success even when they failed. Your verify function should check for concrete evidence: was the expected action taken, did known failure patterns (login redirects, error pages) appear? Return pass or fail based on code logic, never the model's final message.

How does the Tejas Harness Framework compare to prompt engineering for fixing AI agents?

Prompt engineering tries to control a non-deterministic model by refining instructions — an inherently fragile approach. The Tejas Harness Framework wraps the model in deterministic code that enforces correct behavior regardless of model quality. In Tejas's original demo, the system prompt was never changed; only harness additions (guardrails, verify steps, handlers) made the agent succeed. The harness approach is model-agnostic, meaning you can swap models without rewriting prompts.

When should I use a harness instead of upgrading to a better AI model?

Use a harness whenever you need reliable, repeatable outcomes from an agent — especially before spending more on a frontier model. A cheap model wrapped in a solid harness outperforms an expensive model running unharnessed. Upgrade the model only after the harness is in place, as the harness is what provides deterministic guarantees for authentication, secret handling, context management, and result verification that no model can provide on its own.

What inputs do I need to start building an agent harness?

You need two required inputs: the specific agent task stated plainly and the current failure mode (how the agent is failing — lying, crashing, looping, etc.). You also need to know your target model, though it can be any LLM since the harness compensates for model weakness. Optionally, list external systems the agent must interact with and any secrets or credentials that the harness will inject deterministically.

What results can I expect after applying the Tejas Harness Framework?

You can expect a previously unreliable agent to complete tasks deterministically and report failures honestly. Agents stop lying about success, stop looping endlessly, handle authentication walls automatically, and stay within context limits. In practice, even agents running on cheap or small models achieve production-grade reliability. You also gain a reusable, composable harness abstraction that works across different tasks and models with minimal modification.

What is a verify step in an agent harness?

A verify step is a deterministic function written in code — never delegated to the model — that inspects the agent's trace after each attempt and returns a definitive pass or fail. It checks for concrete evidence of success and known failure patterns such as login redirects, missing form submissions, or error events. The verify step removes the model's ability to self-report success and is the primary mechanism that eliminates agent lying.

Can I use the Tejas Harness Framework with any LLM?

Yes, the framework is explicitly model-agnostic. The harness compensates for model weakness, so you can use GPT-3.5-class models, open-source models, or any cheap LLM and still achieve reliable results. The model is treated as a swappable black-box renter; all stability comes from the harness. This is especially valuable for teams that cannot afford frontier models or want to reduce API costs without sacrificing reliability.

What are deterministic handlers in an agent harness?

Deterministic handlers are harness-owned functions that intercept the agent loop at specific conditions and perform critical actions in code without involving the model. For example, a login handler checks the browser URL every iteration; if it detects a login page, it injects credentials from environment variables and submits the form programmatically. The handler then notifies the agent it can proceed. Secrets never enter the model's context window.

// GET STARTED

Turn Any YouTube Video Into An AI Skill

SkillForge captures a creator's exact methodology from their video and turns it into a reusable AI skill you can invoke in Claude, ChatGPT, or any LLM.

Forge your own skill