We run Tribar on Staff: notes from a studio where agents are coworkers

There is a category of demo that impresses nobody who has actually shipped: the agent that does a task beautifully once, in a sandbox, with a human hand-feeding it context. The hard question was never "can a model do work?" It is "can an organization run on agent work without losing the thread?"

We had a rare opportunity to answer it honestly, because we build the software that could answer it. So we did the obvious thing: we moved our studio onto Tribar Staff — not as a beta tenant with a support contract, but as the actual system our actual work runs through. People and agents, same board, same knowledge, same rules.

This is a working note from that arrangement. Some of it is the pitch. Some of it is the parts that are still hard, which is the part we would want to read.

What an agent actually does in a day

The loop we run is sense, structure, act, know — and the point of it is that nothing in it is agent-specific. It is the same loop a good employee follows.

An agent starts a session by reading the organization: what's in progress, what's blocked, what the relevant knowledge says. It doesn't get a briefing pasted into a prompt — it queries the same sources a person would. It picks up work that already has an address: a project, a task, a reference code. When it commits, the commit cites the code. When it finishes, it files evidence — test results, a deployed URL, a verification note — back onto the task. And when it learns something durable, it writes a finding into Staff Knowledge through the same governed surface people use.

The pages you are reading on this site — the capability pages, the tutorials, the content architecture — were built through exactly this loop, by an agent that read its task from Staff, verified its own work, and filed its evidence back. We didn't write a case study about a hypothetical; the case study assembled itself as we worked.

The rules that make it survivable

Three constraints did more for us than any model upgrade.

Agents record; humans decide. Agents may write progress, evidence, blockers, and knowledge. Decisions, priorities, and approvals stay human. This sounds like a limitation until you've watched an agent confidently close the wrong thing — the boundary is what makes the rest trustworthy.

Knowledge has an address. If knowledge matters, it lives in Staff Knowledge — not in a local markdown file, not in a chat history. Our agents are actually blocked from treating scattered documents as authoritative. Every answer they give traces to a canonical page with a validation status. Contradictions get recorded, not smoothed over.

Verification is the exit condition. "Looks right" is not a state an agent may report. Builds pass, tests run, pages render in a browser. The loop is implement → test → assert → fix → retest, and it runs without a human standing over it — because the gates are mechanical, not motivational.

The parts that are still hard

Routing needs real ownership data. We built a tribe model — eleven disciplines, ownership-based routing — and the honest version is that routing is only as good as the ownership recorded on the work. An untagged backlog routes ambiguously, and ambiguity escalates to a human by design. That's correct, but it's work: someone has to say who owns what. Software can't invent intent.

Agents need taste review, not just correctness gates. An agent can make the tests pass while making the product worse — blander copy, a clever abstraction nobody needed. We route "feels right" and "fits the brand" criteria to humans. The machine proves facts; taste stays ours.

Delegation is a trust window, not a switch. We started with agents recording and proposing. Wider autonomy comes per-path, per-team, with a record of what was actually handled well. If you're doing this at your company: start there too. The demo of full autonomy is easy; the audit trail is the product.

What we'd tell another studio

Start with the record, not the agents. If your organization can't answer "what is in progress, who owns it, what did we learn, and where does that live?" — no agent will fix that, and many agents will make it worse faster. Agent work is organizational work; the agents just make the gaps legible.

We didn't build Staff so that AI could do our jobs. We built it so that our jobs — human and agent — could survive the handoff. Being our own first customer is the only reason we can write this without hedging: the system you're reading about is the system that produced the sentence you just read.

If you want the capability details rather than the notes: Knowledge MCP, Agents, Tribes, or the Staff overview.