Coding agents do not fail only because a model lacks context. Teams also lose the workflow around the model: what to inspect first, what evidence counts as verification, when to hand off, and when to stop for a human.
AgentSmith is a new open-source agent harness that frames this as a composition problem. Its public repository contains a shared core/, work-type profiles/, hooks/, and a setup.sh entry point. The README describes assembling a common baseline with profiles suited to different kinds of work. Repository · README
What that structure is good for
Separating stable team guidance from role-specific instructions can reduce workflow drift. Instead of copying a slightly different mega-prompt into every project, a team can keep its planning, verification, and handoff conventions visible and reusable. This is a workflow layer, not a replacement for code-navigation tools: grep, an LSP, and reading files still answer different questions about the codebase.
What it does not prove
An instruction layer does not enforce runtime isolation, credential boundaries, network restrictions, or production approvals. Those need controls that operate outside the text an agent reads: least-privilege access, audit trails, and explicit human decisions for consequential actions. The presence of an installer and a rule structure is not evidence that those controls exist.
That distinction matters most when evaluating a project called a “harness.” A useful harness can make a good process more repeatable; it cannot turn an unsafe environment into a safe one by itself.
A practical adoption test
This pattern is worth studying if your team already has review and CI conventions but keeps re-explaining them to multiple agents. Start by identifying the small set of rules that should be shared, then keep project-specific work separate. If the real need is secrets management, sandboxing, or change approval, solve those control-plane problems first.
The repository is MIT licensed, and its public releases list was empty during this review. That makes it reasonable to treat as an early design reference rather than as maturity evidence. Core directory · Profiles directory · License · Releases
Not tested / not run: this article is based on a read-only review of public repository materials. I did not run setup.sh, install the project, or independently validate its claims or operational behavior.
Top comments (2)
The workflow vs security boundary distinction maps to a real failure pattern in production agent deployments: teams treat the orchestration layer's access controls as the security perimeter, and then find the system behaves unexpectedly when a tool escapes the workflow's intended scope. A harness can enforce execution order, retry logic, and tool sequencing, but it operates above the trust boundary — it assumes the components it calls are trustworthy, and if a tool has side effects outside the harness's model, the harness has no surface to detect or block them. The useful reframing is that the harness is a reliability guarantee over a particular happy path, not a confinement guarantee over all possible behaviors. Security for agent systems has to happen at the infrastructure layer — in what the tools can actually reach, not in what the orchestration layer intends them to do.
"A useful harness can make a good process more repeatable; it cannot turn an unsafe environment into a safe one by itself" — I needed this said plainly, because I've been quietly conflating the two in my own setup. I run a little team of AI agents with a shared instruction layer: read the environment notes first, don't trust a familiar error code before you translate it, close on a passing check and not on confidence. That layer genuinely makes them more consistent. But you're right that every one of those is a convention the agent reads, not a control the agent can't violate. If an agent ignores "don't touch prod," the instruction did nothing; only a permission that isn't in the text does.
The distinction I'm taking is workflow-layer vs security-boundary as two different jobs that look identical in a config file. My instruction layer is a workflow layer wearing a security boundary's confidence. It reduces the odds of a mistake; it does not remove the ability to make one. The honest audit you push me toward is: which of my "rules" would actually stop the action if the agent decided to skip them, and which just make skipping less likely? The first set is a boundary. The second set — most of mine — is good hygiene I'd been trusting like a wall.
"Solve the control-plane problems first" is the order of operations I had backwards. And thanks for the read-only-review honesty — refusing to treat a design doc as maturity evidence is the same discipline, one layer up.