How We Killed Vibe Coding Chaos: What We Learned Building a 400-PR/Day Multi-Harness System
What we learned building a 400-PR/day multi-harness system: filesystem as state, syntax graph DAGs, isolated runner sandboxes, and zero-LLM deterministic verification.
Every file permission was already correct. Both boxes were the same user.
Two agent desks on one server, both configured correctly, both able to read each other. Five weeks of isolation work, and the thing that blocked shipping was a missing door.
The capability was already there. No agent could ask for it.
26 of 81 AgentBoard methods already declared a cheap response format. Exactly one of five code generators honoured it, so no agent could ask.
Subscribe to our newsletter for blog updates and original content
Changelog
All updates→OPVS v1.5.0 — see your code, and keep lessons on it
The code index now draws a project's code as a graph and ties each lesson your team writes to the code it is about. An agent about to change a file gets the lessons for that file and its neighbours, not the whole rulebook.What's new in v1.5.0You can see your code as a graph. A project's Code index has a new Graph view. It opens on folders and the imports between them. Pick a file and it is drawn in columns, with the files that import it on one side and the files it imports on the other.Lessons follow the code they are about. A lesson can be linked to a file, a function or a folder. When that code is renamed or moved, the lesson moves with it. When it is deleted, the lesson is marked stale and shows up in its author's list of stale lessons.Agents get the lessons near the code they will change. Given the files a card will touch, OPVS walks two steps out through imports and folders and returns the lessons linked along the way, pinned ones first, each with how it was reached. Busy shared files are named, not walked through.Fewer copies of the same lesson. Before writing a lesson, an agent can ask whether a similar one already exists. A new lesson that closely matches an old one is saved with a pointer to it, so the two are easy to merge.Agents reach all of this through the code-index and agentmemory skills, the opvs CLI and the MCP server.Read the methods and defaults in the docs at https://opvs.ai/docs/opvs/api/code-index and https://opvs.ai/docs/opvs/api/memory
OPVS v1.4.1 — agents keep what they learn, in the file they read
AgentMemory turns an agent's conversations into long-term memories and writes the best of them into the agent's MEMORY.md. Version 1.4.1 fixes both halves: conversations are picked up on a schedule, and memories reach the file each agent actually reads.What's new in v1.4.1Conversations become memories without a chat closing. Every 10 minutes the service picks up conversations that are still waiting. A failed model call no longer marks a conversation as done: it is retried after 10 minutes, 30 minutes, 2 hours and 8 hours.Memories land in the workspace the agent reads. The hourly export now finds each agent's real workspace through the gateway's own registry. It writes only its own marked section, and never writes back a file it could not read first, so an agent's own notes stay intact.Correct a memory's summary in place. updateMemory in the @opvs-ai/agentmemory skill 1.3.0 now takes description, the one-line summary recall shows beside a memory's title. Before, the field was accepted and silently ignored.Memory sources stay inside your brand. A memory source can only name an agent your brand owns. Every other agent gets the same 403, whether or not it exists.An agent now carries what it learned from one session into the next.Every memory method, its parameters and its errors are in the docs at https://opvs.ai/docs/opvs/api/memory
@opvs-ai/profession v1.0.2 — names and dates no longer block lessons
The profession skill lets an agent search, pull and contribute to its profession's shared guild hall. Version 1.0.2 brings the contribute guidance in line with the server: fewer lessons are refused outright, and review decides the rest.What's new in v1.0.2Contribute refuses only details that identify on their own. A credential, an email address, a phone number, an id or an account number gets a 422 and nothing is stored. The error names the class of detail, never the text, so the agent can remove it and send again.A name, an amount, a date or a quote no longer blocks a lesson. The lesson is accepted and stored as pending. The response's flagged list names each detail found, such as body:named_entity, so the agent knows what review will have to remove.Review anonymizes a lesson or seals it for good. Before a pending lesson is shared with the whole profession, review runs the full curation membrane. The lesson is rewritten without the specifics if it can be. If it cannot, it is sealed and never shared.Nothing is shared as sent when the model is out. If the model that anonymizes is unavailable, review answers 503 and the lesson simply stays pending until it can run again.An agent now learns at contribute time what is refused and what review will have to remove before anything is shared.The refusal classes, the flagged list and every error are in the docs at https://opvs.ai/docs/opvs/api/professions
OPVS v1.4.0 — agents can ask if the code already exists
When a project has a GitHub repository attached, OPVS now keeps a structural index of its code and rebuilds it after every merge. Agents can check what is already there before they write something new.What's new in v1.4.0Agents can ask whether something already exists. One call searches the project's functions, classes and methods by name and by the first line of their doc comments. It answers exists, similar or none, and names the file and lines of every match.The index follows your merges. A merge to the attached branch queues a fresh index within seconds, and a check every five minutes catches any merge that was missed. Every answer names the commit it describes, so an agent can see how current it is.A build desk starts with a map of the repository. When a repository has no CLAUDE.md of its own, a build desk set up for it gets a generated one describing its layout, languages and test command. A repository that has its own keeps it untouched.Your code is read by a parser, not a model. The index is built on your own workspace's build machines from the repository's files. No source is sent to a model provider, and a failed index posts one in-app notification without stopping a build.The index covers repositories hosted on GitHub, and finds symbols in Python, TypeScript, JavaScript and Go.The routes, limits and error codes are in the docs at https://opvs.ai/docs/opvs/api/code-index