Loop Engineering and the Tessl Agent: Building a Software Factory That Improves Itself

A new wave of engineering teams is discovering something unexpected: the hardest part of deploying AI coding agents isn't getting them to write code. It's building the infrastructure to make them continuously better at it — without turning that infrastructure into a full-time job.

Dru Knox, Head of Product at Tessl, sat down with the AI Native Dev podcast to introduce the Tessl agent and to explore the philosophy behind it. The conversation turned into a precise and practically useful examination of what loop engineering actually means, why software factories need to be open and modular, and how teams can begin building toward serious agent autonomy without stalling their delivery pipelines.

What the Tessl Agent Actually Does

The Tessl agent is, at its core, a new interface to the Tessl platform — connecting the skills, context management, and evaluation capabilities Tessl has been building into a single, conversational CLI agent. In use, it feels familiar: terminal-based, similar in interaction model to Claude Code. But its purpose is distinct.

"The Tessl agent is a factory building agent," Knox explained. Its goal is not to replace interactive coding sessions but to help teams graduate out of them — setting up automated loops that handle recurring work, surface failures, and propose improvements without requiring a human to initiate each cycle.

The design philosophy is deliberate. The agent is built to sort of almost get you to stop using it, Knox noted. You work with it, and at the end of a session it will suggest recurring automations: CI/CD checks to set up, feedback loops to run on a schedule, patterns to encode as skills. The endpoint is a software factory that largely maintains and improves itself.

Loop Engineering: The Right Place to Start

To make sense of how teams should approach agent deployment, it helps to plot the challenge across two dimensions: speed of delivery and depth of agent autonomy. Most teams discover these pull against each other in ways they didn't anticipate.

Knox described the pattern clearly. When an agent makes a mistake mid-task, developers face a choice: push through and ship the feature, or pause, roll back, and do the science to stop the agent failing in the same way again. Teams tend to split into two categories. The first group ships everything and their agents never meaningfully improve — stuck in what Knox calls a "local maximum." The second group invests in autonomy but takes a velocity hit that can last months.

Loop engineering aims to dissolve that dilemma. Instead of treating agent improvement as a discrete project, teams set up a loop: a recurring automated flow that observes agent behaviour, surfaces mistakes, proposes fixes, and tests those fixes against historical scenarios. The result is incremental improvement that runs alongside normal delivery — not instead of it.

"The loop handles the grunt work," Knox observed. "Actually putting up the PR that says, I saw this mistake, I think this fixes it — and it allows you to focus just on, oh yeah, that makes sense." The compounding effect is significant. Teams that start with PR code review will find — without any deliberate push — that the share of PRs without a human reviewer climbs steadily over weeks and months.

How AI Agent Evaluation Happens Automatically

One of the more underappreciated aspects of the loop model is how it generates evaluation data as a byproduct of normal work. Writing evals is notoriously unpopular among developers. Loops sidestep the problem.

When a loop observes a code review failure, it doesn't just flag it — it extracts an eval scenario from it, runs the proposed fix against that scenario, and confirms the improvement before raising a PR. Teams end up with a growing library of real-world test cases without anyone having to author them deliberately. The AI agent evaluation framework builds itself from production signal.

The Open Factory Argument

Knox made a pointed case for why the architecture of the software factory matters as much as what runs inside it. The argument turns on ownership.

The factory a team builds — the code review standards, the workflow logic, the skills that encode how they want agents to behave — represents institutional knowledge that compounds over time. If that knowledge is locked inside a closed platform, the platform provider has pricing leverage over it. "They say, hey, everything that makes your company you is in our ecosystem. And so we're going to crank up the token cost," Knox noted. The team that spent months building their factory discovers they can't move it.

Tessl's position is that factory platforms should behave like platforms — not end-to-end solutions. Good defaults for teams that don't want to think about specific components; full extensibility for the parts they care about. Critically, the intelligence — the skills, the evals, the context — should live in files the team owns and can port to any agent or provider.

Cost, UX, and What Comes Next

On agent cost management, Knox offered advice that runs counter to the instinct many teams have. Trying to optimise at the level of individual model selection — planning with a frontier model, delegating to a smaller one — is "a bit of a losing game." The better approach is to identify which automated loops can run reliably on smaller, cheaper models, and encode that at the loop level rather than the session level.

On UX, Knox observed that AI agents have fundamentally reset developer expectations. Users now expect to speak in outcomes — "make agents work in my front end" — and have the tooling handle the translation into specific actions. That shift demands a new kind of product thinking: interfaces that stay stable while the underlying capabilities change rapidly beneath them.

For teams curious to try it: run npm i -g @tessl/cli and then tessl to open a session. Ask it to set up code review, or simply ask what work could be delegated to agents. The loops follow from there.