Each agent was briefed in a different chat
The spec agent, the delivery agent and the review agent each got a slightly different prompt. None of them saw the version your client agreed.
For software teams
Keep every coding agent on the spec.
Your agents read the same published spec and acceptance criteria, propose changes to them, and report pull requests and test runs against the criteria. You see who did what, on one Feature.
Sound familiar?
Three agents, one Feature, no single version of the plan.
“Done” means “the agent said so”
The pull request says it’s finished. Nobody checked it against the acceptance criteria, because the criteria lived in a ticket comment.
Nobody can say who changed the spec
The page history shows a person’s name, or an automation. You can’t tell which agent made the change, or under whose key.
One Feature, end to end
From two lines to production, with a record at every gate.
1
Write two lines
On the Feature card. That’s the brief.
2
Your spec agent drafts and proposes
It reads the card and its format template, drafts the spec and the criteria, and proposes them. get_feature_pack get_document_type_prompt propose_feature_pack_change
3
You accept, then publish
You read the diff and accept, and the draft updates. Publish it and the spec gets a new version. The proposing agent can’t accept its own work.
4
Your delivery agent builds and reports
It builds against the criteria, reports the pull request and the test run against criterion ids, and proposes the move to Testing. get_feature_sdlc propose_feature_sdlc
Staging and production moves also need a recorded deploy of that Feature to that environment, at a full commit SHA, never from a feature branch. An agent can still file that pin itself through report_bot_activity. The pin doesn't move the stage; a person still makes the move.
What you get
The contract your agents build against, and the evidence they did.
Acceptance criteria as data
Given / when / then, stored on the Feature. Your team reads them; agents read and propose changes to them through your organisation’s hosted agent endpoint.
Proposals with a diff
Agents propose changes to the spec, the criteria and the stage. A person accepts or rejects stage and feature-pack proposals. Stale proposals fail.
One key per agent
Each agent is its own user with a named key, scoped to the Products and cards you choose. For agent keys, an empty allow-list means denied: one-step setup won't create one, and any agent key left empty is refused every call. Revoke in one click.
Eleven delivery stages
Ideation to production, with deploy pins for staging and production. Agents propose stage moves. A person accepts or rejects those stage proposals, including starting delivery and clearing a stage that is already set.
Test runs mapped to criteria
Agents report pull requests and test runs against criterion ids, so you see which criteria pass on the Feature itself.
Defects agents can log
Agents log, triage and update defects through your organisation’s hosted agent endpoint, with resolution notes kept on every one.
Connect GitHub
Pull requests, checks and deployments sync to the Feature automatically. Mataara never reads your code.
Evidence pack
One file per Feature, change request or release: spec version, criteria results, approvals, acknowledgments and agent activity. Feature packs on Plus; change requests and releases on Business.
Sign in with GitHub, Google or Microsoft
Use the identity your team already has. No new password.
Works with your stack
Keep your tracker. Mataara holds the spec it’s built against.
Keep Jira, Linear or GitHub Issues for tickets and sprints. Mataara holds the published spec, the criteria and the evidence. Any agent connects through your organisation’s hosted agent endpoint: Claude, Grok, Cursor and others.
Get set up
Four steps to your first agent proposal.
1
Register
Create your organisation and choose a plan. Agent access keys are on Business and Enterprise.
2
Add a Product and a Feature
Product, Domain, Sub Domain, Feature. Empty levels stay out of the way.
3
Set up your agent
Setup external agent creates a bot user, a named key and a config to paste into Claude or Grok. That setup is on Business or Enterprise.
4
Ask it to work from the plan
“Read the Feature in Mataara and draft the acceptance criteria.” Then accept or reject the feature-pack proposal.
Questions
Straight answers for engineering teams.
Does Mataara read our code?
No. Mataara never needs repository contents. Agents report pull requests and test runs to it. The GitHub connector on our roadmap reads pull-request details, checks and deployments, never code.
Can an agent run without a person?
It can read, draft, report and propose. It never accepts its own proposals. Only a person accepts a stage or feature-pack proposal, moves a delivery stage, starts delivery, clears a stage that is already set, or edits acceptance criteria directly. Only a person publishes a managed or card document. That covers everything you can publish in Mataara. An edit key can still edit cards, write card documents, and delete a card that has no child cards, no Feature that still names it as its Domain, and no published document attached. Creating a card needs its own access. See the Security page.
Do we have to replace Jira or Linear?
No. Keep your tracker for tickets. Mataara holds the spec and criteria your tickets are built against, and the record of what was delivered.
Which plan do we need for agents?
Agent access keys are on Business and Enterprise. See Pricing.
Try it on your next Feature
Put your next Feature in Mataara and point an agent at it.
Register, add a Feature, and on Business or Enterprise set up an agent and accept its first proposal.
Compare plans: Pricing. Questions? Talk to us.