questions
Nothing here is about anyone else's product. Every answer is about what Wovu does, what it does not do, and what you would be able to check for yourself the day the repository opens. Where a number appears, we measured it on our own build.
nothing on this page has shipped. it is the specification the build follows, and every mono line names a real tool, table, column or command in it.
the obvious objections
No, and it does not replace them. Keep your worktrees. They stop two agents writing over each other's files, which is a real job and a different one. Wovu is the part that carries something between them: one board both agents read and write, a run somebody else started that you can join and redirect, and a project that still has its thread six months later. A worktree ends when the shell does. The board does not.
Easier to build, and much harder to get approved. Wovu is installed inside somebody's employer's network, and the person who approves it is rarely the person who asked for it. Companies say plainly that they cannot send proprietary source and prompts to a third party's servers, so a hosted version would fail at the one conversation that decides whether it gets used at all. Self-hosting is not a principle here, it is the shape that survives a security review.
No. Everyone keeps the tool they are fast in. Wovu is not an agent and does not run one: it sits underneath whatever each person already chose. One command writes the config file for the four tools whose layout it knows, and anything that speaks MCP can connect by pasting two values.
It varies by tool, and this page will not pretend otherwise. Claude Code has hooks, so file edits, shell commands and cost arrive live. Codex is read after the fact, from the state it already writes to disk. Everything else reports through the MCP stream itself, which is thinner, always present, and the reason the boundary can be the protocol rather than a list.
a screen with the live hook feed behind it is labelled a live session. one with only the MCP stream behind it is labelled activity. the naming is part of the build rules, not a preference.
That is the failure mode to design against, so: entries are typed and scoped, an agent asking about one task is not handed the whole workspace, and search says out loud when it is running in a reduced mode instead of quietly returning less. Corrections a human makes in the review queue become rules with an owner, a count of the times they fired and a date they get looked at again, so nothing accumulates forever without somebody's name on it.
memory, and why this is not one
A memory tool saves notes and waits to be asked. That is two chances to fail: the note has to be retrieved, then it has to be obeyed. We measured it on our own build before writing a line of this page. With a shared board sitting there for the agent to query, it queried zero times. Not rarely. Zero.
Wovu does not wait to be asked. The work state lives outside the session, and a briefing is composed from the record and delivered before the agent's first turn. Nothing to search for, nothing to remember to read. The same knowledge that sat unread in a store arrives as the starting context instead.
the briefing is a deterministic view over the event log and the board, not a model summarising things: same inputs, same briefing, byte for byte.
A gate, and it is the part nobody else ships. Before anything an agent writes counts as knowledge the fleet acts on, it is checked: does it contradict what is already there, do the files it refers to still exist, and does the recorded outcome of the run agree with the claim. Verdicts come from exit codes, test results and human decisions, never from a model's opinion, and no agent can write one about its own work.
When something later turns out to be wrong, the entry is retired and every session that read it is listed, so you know exactly what to look at again rather than guessing.
A file like that is a good instinct and it is where most teams start. It also has to be written by a person, kept current by a person, and read by an agent that may ignore it, and it grows until nobody trims it. The board is written as work happens, scoped so an agent asking about one task is not handed the whole workspace, checked before it counts, and superseded rather than edited, so the history of why something changed survives. If a file still works for your team, keep it. This is what to reach for when it stops.
Nothing can stop a person losing interest, so the honest answer is the licence. MIT means the code you install is yours to keep, fork and run whatever happens next, and the data is in your own database on your own machine rather than in an account you would lose access to. That is the only guarantee anybody can actually give you at this stage, so it is the only one on this page.
your code, and whoever signs this off
They stay where they are. Wovu starts an embedded database inside your repository and runs the same code against your own Postgres when you want it to. There is no cloud in the path, so there is no step where it phones home. Telemetry is off until somebody turns it on, and the switch is a command, not a support ticket.
It gets refused rather than stored. Every write is scanned before it is committed, a confident hit is rejected, and the offending field is named back to the agent so it can try again without it. Nothing is written, and the audit row records that a write was blocked rather than recording the secret.
Permissions are checked inside the services, once, for every way in, and the default is no. An agent carries its own scoped key and its own list of tools it is allowed to call, and it can never hold more than the person who issued it. An entry restricted to named agents is absent from everyone else's search results, not merely hidden from a list.
Every instruction, approval, denial and admin action is a row in a hash chain, so a missing or altered row is detectable rather than invisible. It holds metadata only: who, what, when, and a reason. No content and no secrets, so the audit log can never become the thing that leaks.
Offboarding deactivates the member and keeps the knowledge. Their agents' entries, sessions and handoffs stay with the workspace, still attributed to them, so the person who inherits the project inherits the reasoning as well as the code.
when, and what to do now
I do not know, and a date invented here would be the first thing on this site that was not true. The gate is a demo path that runs end to end: connect a real agent, watch it, redirect it, hand it off. When that runs, the repository goes public.
Two reasons, both boring. There is no demo path yet, so opening it today would ask people to evaluate a half-built thing from its file tree. And it gets a full history secret scan before it opens, because a repository is opened once and every commit that was ever in it opens with it.
Two useful things. Watch the repository, so the day it opens you are not finding out from a launch post. And tell me what your team runs and what this would have to do before you would put it on your own box, because that answer is what decides the order the rest of it gets built in.
zubairaslam40@gmail.com
everything it does
Nineteen things, grouped under the four questions a team actually asks. The mono line under each label is the primitive that implements it.
One board per workspace, append only, written by the agents as they work and read by the next agent before it starts.
Two people with agents are two people editing the same repository at machine speed. Wovu makes the other agents visible and the contended things claimable.
The output of a team of agents lands on a human who has to sign for it. This is the part your lead reads, and the part your security review asks about.
The question somebody asks six months later, usually about code no human wrote and nobody remembers reviewing.
none of this has shipped. the story it fits into is on the homepage.
still not answered
If the question that would decide it for you is not on this page, that is the useful thing to send me. It goes on the page, and it moves the build order.