For Every Role

Something honest first. AI coding agents are absorbing more of the implementation work every quarter. The work that stays human is judgment: deciding what should be built, weighing the tradeoffs, catching what the agent got wrong, and carrying the reasoning forward so the next decision is easier. That work looks the same whether your card says business analyst, senior developer, product owner, or architect — the titles were drawn for a world where writing the code was the scarce skill.

The platform is built around that judgment work, not around the titles. So instead of separate guides telling each role what it's for, this is one guide: the same loop, entered through whichever door fits how you think. Nobody's door is a service window onto someone else's product.

Roles are trust, not titles

Workspace roles say how much the org trusts an account — they say nothing about what kind of work you're for:

A business analyst and a principal engineer are both contributors, with the same authority. There is no approval chain between job functions: a contributor can write a spec, approve it themselves, create the intents, and confirm delivery — or author a technical intent and release it — without anyone else's title in the way. Review stops exist where a team wants them (a spec's optional In Review, an intent's unreleased stage), but they're workflow you opt into, not hierarchy.

One review is mandatory, and it's the right one: human over machine. Anything a plugin run or chat proposes lands unreleased and waits for a person to release it. People check machines; people don't gatekeep people.

One loop, four doors

Everything on an app board runs the same loop:

1. See what exists. The board is a living map built from the code itself — systems, connections, aspects, findings — not a diagram somebody drew last spring.
2. Decide what should change. As a spec (an outcome with requirements) or directly as an intent (a concrete work item) — both meet in the same queue.
3. The work flows to the repo. Developers pull the queue into their coding session with /intents; the change is implemented where code is actually written.
4. The change comes back. The next /sync from the repo pushes what actually landed — the map updates itself, intents that proposed a structural change are verified against the code, and a spec requirement turns Delivered as the intents under it resolve.

The doors below are just steps into that loop from different directions. Take any of them; they all reach all of it.

Different doors, one funnel

However work enters — created from a spec requirement, created from an insight finding, captured from a board edit, written by hand, filed by a plugin — it converges on the same queue with the same lifecycle, tagged with where it came from. Nothing downstream cares about the author's title; everything downstream shows the provenance. That's the design in one sentence: no walls between people, full memory of what happened.

What's next