Your agent is more than its model: Why Parloa engineers have doubled down on the agent harness

You ask your employee to complete a task. They miss the goal completely. It could be them, but it could also be that you didn’t give them the right context, that they weren’t clear on the expectation upfront, or maybe they needed a piece of research that lived only in your head. Needless to say, there are many reasons your employee could have underperformed, and their skillset is just one of them.

The same can be said for AI agents. If an AI agent misbehaves, it’s easy to blame the model. Replace that, and things should work just fine. But that’s not reality.

Years of building with enterprise teams have taught us that the model isn’t the bottleneck. Everything else around it, the configuration that tells it how to behave, the skills it can call, the orchestration logic that routes between tasks, and the guardrails that keep it from going off-script, is. That’s why the harness is where Parloa builds, ships, and invests many of its resources.

How Parloa defines an agent harness

We consider agent harnesses to be the scaffolding around the models. Every agent requires a harness, and in some instances, this means designing a harness for every individual AI agent. But that doesn’t scale, which is why, at Parloa, we design the harness as a composable architecture. Elements can be added to the foundation on a per use case basis. 

Here are a few components we consider essential to the harness:

Subtask agents: Instead of one monolithic agent trying to handle every scenario, we architect Parloa agents as a set of subtask agents. Each agent is responsible for a specific intent or resolution path and is bounded by scope. This makes routing governable. You can test, audit, and fix individual subtask agents within the harness without disturbing the agent as a whole.

Skills: These are the actions agents can take: look up an account, verify an identity, process a return, etc. They’re discrete and reusable, making them able to be validated independently and composed across agents. If the agent underperforms, you’re able to solve the problem by debugging a skill, not reverse-engineering a monolithic prompt.

LLM guardrails: LLM guardrails are the detection layer within the Parloa agent harness, sitting alongside Subtask Agents and Skills to catch inputs and outputs that should not reach the customer. They operate at two levels: one that evaluates each message individually for policy violations as it passes through the platform, and one that runs across the full conversation, detecting patterns a message-level check cannot see. These could include an agent drifting outside its defined scope or a caller systematically probing for a way past the agent's constraints. Unlike other harness controls that enforce fixed rules, guardrails use an independent model to evaluate outputs, which makes them suited to the violations that cannot be defined in advance.

Together, these three components, when integrated with pre-existing workflows and systems, provide the specificity and uniqueness that is essential to each business’s agentic system.

Even the best harnesses still drift

While harnesses reduce the variance that occurs with the non-deterministic nature of LLMs, they don’t eliminate it entirely. There will always be a chance that the agent will fail, and the role of the agent builder is to be able to figure out why it failed quickly before the problem is replicated.

Historically, agent debugging has followed the process of pasting a failed transcript plus a large prompt into an LLM (ChatGPT for example) and asking for the AI to figure out what went wrong. But the LLM has no direct access to the agent. It doesn’t know the agent’s platform conventions and can’t access the underlying configuration, so its assessment is based on the limited knowledge you’re able to input into the system. As a result, the LLM provides a plausible diagnosis, but it’s not grounded in any of the specificities you worked so hard to build, and you can’t test it before implementing it into the live agent. All inaccuracies have to be sent back to highly skilled agent builders who understand code and AI well enough to debug the agent through a frustrating system of trial and error.

That’s why Parloa has brought harness testing into the agent itself.

Parloa Navigator

Recently, Parloa announced a new component of its platform, Parloa Navigator, an AI agent that sits inside the platform to diagnose problems, make recommendations, and iterate directly on your agent. Because it has direct access to all of the components of the AI agent, it can read a failed conversation and trace back through the system to find the root cause. Then, it can propose precise, line-level fixes that can be reviewed, accepted, or rejected before implementing into the live agent, all while keeping the work in the business unit and outside of IT’s queue. 

How it works

Navigator covers three key capabilities: create, improve, and debug. Create takes builder artifacts such as flowcharts, SOPs, and API specs and generates a working first-draft agent. Improve is where human builders can add capabilities through a conversational interface that automatically get applied to the configuration. Builders can analyze complex agents for structural issues, review recommendations made by Navigator, approve them one-by-one, and re-test the agent before go-live. When Navigator debugs a failure, it reads the same configuration that produced it, tracing the failures back to their source with platform-grounded analysis.

With Navigator, root-cause analysis that previously took hours of config review and external model consulting can resolve in under a minute with an agent builder within the defined business unit.

A look at Navigator in action

Here’s an example of how it all works:

An AI agent is designed to handle printer issues. Its harness includes a subtask agent dedicated to printer troubleshooting with an activation restriction: Only activate when s

serial_verified = true. 

But the serial number collection step lives inside the resolution instructions of the printer troubleshooting Subtask Agent, meaning that the activation condition requires something that can only happen after activation. The process is backwards and leads to a broken handoff. When a customer asks for help with their printer, the agent routes to human escalation rather than to the printer troubleshooting flow. 

Where most teams would spend hours trying to debug the agent, looking at its traces, putting transcripts into LLMs to debug, and testing through a series of trial and error, with Navigator, an agent builder could paste the conversation URL and simply ask the question, "Why is the agent not handing over to the printer troubleshooting subtask agent?" 

Navigator, with its full view of the agent harness (configuration, operating model, tools, etc.) would then read the conversation, trace the logic, and surface the conflict. It would propose two changes, either modify the activation instruction or remove the blocking activation restriction, and then show what both situations would look like. The builder can review all of the options, which trace down to individual prompt lines. With this transparency, they can test the provided recommendations, accept them one-by-one or all together, and then re-run the conversation. They can test it again to make sure the handoff works as expected before implementing it into production.

Human judgement still prevails

Navigator is designed to remove the bottleneck to AI agent development and optimization, empowering agent builders to design and implement changes to AI agents that ensure optimal performance within their lines of business. While Navigator democratizes agent building by enabling business teams to build AI agents rather than relying on IT and engineering teams, humans are always kept in the loop. No action is finalized without human judgement, ensuring the recommendations are correct and work in production. This ensures reliable AI at scale. 

What’s next

You can’t have an agent without a model. You can’t have a reliable agent without a harness. In enterprise service environments, where any failed experience is a threat to brand loyalty, reputation, and trust, the harness is proving to matter tremendously.

We built Navigator to make agent performance more easily diagnosable, improvable, and accessible. But if the harness ensures the agent is improving, who keeps the harness up to date? More on that in the next article.