What the teams maintain
Three assets, kept alive.
Not projects that shipped and stopped. Each is still under maintenance by an agent team. The last is public, so you can install it and read its history.
Private
The AI-SDLC reference
Delivery end to end on an agentic model, across teams rather than inside one: what gets asked for, how it is built, how you know it shipped. Worked into patterns another team can pick up. It has an agent team of its own, in a private project you cannot open, so that team is not set out here.
Internal · seven agents
This brand
The page you are reading, the deck, the identity and the rules that govern them. One agent each for the claim, the voice, the render, the argument against, the contradictions with what is already published, the path a reader actually takes, and whether the whole thing still says what its sources say.
Public · installable
The plugin marketplace
One of the places the AI-SDLC reference is tested, and the one in public. Plugins are added as problems are worked through. So far: an agent team that helps whoever installs it find their next opportunity, full-time or fractional, and a connector for several mailboxes.
One team, in full
A factory that maintains, not just builds.
These six maintain the marketplace. Generating something with AI is the easy half now. The other half decides whether the thing is still alive in six months: keeping the documents true, the checks passing, the releases loading, and the claims about the system honest. That is the half these six do, and none of them writes features.
All six are agent definitions in a private repository, so you cannot read them. What they maintain is public: a plugin carrying nine installable agents, a connector, their documentation, and a version history you can walk back. That is one product run this way, not an organization.
Most of this is argued at length in the notes, where the index says which of them are one argument with which, and where to start.
Inside AI-SDLC
One capability, across every team it touches.
A roadmap team asks for a new capability in writing. The ask becomes work in other teams’ code, and that work is checked against the ask before it is accepted. The diagram follows one ask the whole way.
Every decision on that path is written down the same way, so a team that did not make it can pick it up:
The options
Constraints differ by organization. Each decision names the real alternatives rather than one best practice.
The signal
A decision table that picks between them, against things you can actually observe. Not “it depends”.
The trigger
The specific, felt pain that says it is time for the more complex option, so you do not buy infrastructure for a problem you do not have yet.
The reference is on no schedule, and this page does not say it is current. It is not published, so the diagram above shows how far the work reaches, not the decisions inside it. Published separately, and standing without it: what the gaps cost, which runs the pieces of infrastructure an agent setup can have in the order they stop being optional, and names some of what exists at each. The layers, and the way to read a tool’s public signals, change more slowly than the tools under them. The tools move on their own schedules, so the list prints dates rather than intervals and says where nobody has looked.
Back
Where this sits.
The argument these are run against is on the home page, worked out at length in the notes, and the machinery half is what the gaps cost.