What Tangigo actually does

A registry of what your organisation has, a control plane that decides what may happen with it, and agent squads that take a story down one build path to a single reviewed pull request. Software products today — organisation, product, module.

The registry

An organisation-scoped record of what you already have, so a new product starts from it instead of re-deciding everything. One list pattern for every kind — owner, version, lifecycle, used by — and every write creates a new version you can compare or restore.

Eighteen kinds, one shape

Agent definitions, skills, tools, APIs, principles, standards, capabilities, data models, reusable components, MCP sources, ADRs, policies, compliance frameworks, credential bindings and more. The columns differ; the screen does not.

A lifecycle, not a status string

Entries move proposed → approved → active → deprecated → retired. Approval is written by the server from the caller’s own identity, so nobody can record themselves as someone else’s approver.

Used by, kept honest

Documents, builds and migrations all write back what they consumed, so an entry knows its dependants. Retiring one that something still uses is refused, and the refusal names what it would break.

Versions you can read

Every change is a version with the principal who made it and the reason it was triggered. Compare two, or restore one, without leaving the entry.

Control plane and governance checkpoints

The registry says what you have; the control plane decides what may happen with it, by whom, and at what cost. Its most important surface is not an admin page — it is a card that appears in the middle of the work.

Checkpoints where the work is

When something deviates from one of your principles, a card appears inline in the wizard, in grooming or in the squad room. It states the rule, the deviation, the blast radius and who has to approve it.

Three honest outcomes

Reject it, grant a scoped and time-boxed dispensation, or relax the principle itself. All three write an ADR and update the registry, so the decision survives the conversation.

Agents are principals

An agent instance has its own identity and its own scope. It never acts under a user’s credentials, and the audit trail shows which agent did what rather than which human was signed in.

Credentials that stay secret

A credential binding is org-readable metadata pointing at an opaque reference. The secret itself is write-only, resolved per call, and scoped no wider than the tool that needs it.

Agent squads and the single build path

A definition plus a control-plane profile is provisioned into named agent instances; a squad of people and agents is staffed onto a backlog item. When that item is built, there is exactly one way it happens.

Definitions, instances, squads

The definition carries skills, profile, default autonomy and its system prompt. Provisioning creates named instances from it. The squad is the set of principals — human and agent — assigned to one backlog item, with roles.

Skills, never raw tools

A skill bundles tools with instructions, a credential binding and policy tags. An agent attaches skills, so what it can reach is a reviewable list rather than an implicit capability.

One isolated job, one pull request

The build runs in a job of its own: clone the repository, cut the branch, run architect → developer → tester over one working tree, commit, push, open a single pull request. Code is never generated in a shared process.

Survives the browser closing

Each phase is checkpointed onto the story and streams live into the squad room. Close the tab and the build carries on; reopen it and you see where it got to and why.

Verified after merge

The merge triggers the test matrix against a baseline held per module and per environment. A type that timed out or was skipped is reported as exactly that — it does not quietly count as verified.

Budgets that actually stop

Model spend is metered against the plan’s credits, and the build carries one budget for the whole squad rather than one per agent.

Documents and diagrams

Specs, stories, ADRs, architecture views and policies are Markdown documents with typed references, versions and an approval state. Diagrams are draw.io, versioned, and referenced by id from the documents that use them.

Markdown, edited in place

A rich editor over a Markdown document, so what is stored stays diffable and what you see stays readable. History, versions and the diff between any two are on the document itself.

Typed references, real backlinks

A reference points from a place in one document to a registry entry or another document, optionally pinned to a version. That gives you backlinks instead of a search across prose.

Diagrams as versioned assets

Embed a diagram by id and it renders in the document and its preview. Edit it and the document picks up the new version; the old ones stay comparable.

Entity diagrams from your data models

ERDs are generated deterministically from the data-model entries in the registry, so the picture and the catalogue cannot drift apart.

Search, and grounding on the same index

One search across documents and diagrams, pre-filtered by what the caller may actually see. The same index is what an agent reads before it answers, which is the whole point: grounding comes from the registry, not from the chat.

Scoped to your memberships

Results are filtered by organisation, product and module access before ranking, so search can never become a way around a permission.

Hybrid, with honest fallbacks

Full-text and vector results are combined and re-ranked. When the vector path is unavailable the response says which mode answered rather than pretending.

The agents use it as a skill

Grounding runs through the same endpoint under the same rules. A turn that could not ground itself gets an empty grounding block that says why, instead of an invented answer.

Skills, MCP servers and published APIs

Tool → skill → agent definition. Everything an agent can reach arrives as an entry somebody owns, which means new capability is added by registering it rather than by editing a prompt.

Point Tangigo at an MCP endpoint and its tools are discovered, reviewed and installed as a skill. Re-discover later and you get a diff: what was added, what changed, what disappeared.

Publish an API, get a skill

An API entry in the registry generates a skill and one HTTP tool per operation, with its credential requirement declared, ready to attach to a definition.

Injected by the gateway

For HTTP tools the orchestrator only ever sends a binding id — the gateway resolves and injects the credential — so the secret never reaches the agent process.

Guarded before it is called

Registered endpoints are checked against private, loopback, link-local and cloud-metadata addresses before anything is stored or invoked.