tatara¶
tatara runs an autonomous development loop on your Kubernetes cluster: it triages your issues, writes code, opens pull requests, and reviews them.
Here is one run, in tatara's own repository, with nothing staged for the demo.
A Grafana alert fired at 2026-08-17T14:01:50Z. No human filed anything: tatara's incident agent investigated it read-only and opened the issue itself, eleven minutes later, with the diagnosis in the body.
Then the platform held it and waited, because an alert is not an instruction and nothing is implemented until a person with commit rights says so. Nearly six hours later, one did, in full:
That comment is the whole approval, and the only one a human wrote on the entire run. What came back was a pull request, and a second pod reviewed it and sent it back: the fix, as written, could have marked a merged pull request closed and rejected somebody else's finished work with a public comment. The agent took that finding, declined half of a different one with its reasons, and round 2 approved. The fix merged as 6f4f5e24, CI tagged v3.4.1, and the cluster ran it.
One comment from one maintainer, two words long. Nine hours of wall clock, with two hours and fifty-six minutes of actual delivery inside them.
One run is an anecdote, so here is the denominator: in the 30 days to 2026-08-18 tatara's agents opened 147 pull and merge requests that reached a terminal state across 15 repositories, 134 of them merged, and the denominator section sets out what that figure does not cover.
Every quote above is from tatara-operator#621, and you can open the thread yourself. Read the whole run, including the review round that caught the bug.
Why it is called tatara¶
That run was not one long-lived process. It was a sequence of pods that each started cold: the one that investigated the alert, the one that wrote the fix, the one that reviewed it and sent it back, the one that rewrote it. The name is the reason that works.
A tatara is the traditional Japanese iron-smelting furnace. The clay stack is built for a single smelt and broken apart to get the bloom out; what carries forward is the iron, not the furnace.
That is the shape of this platform, and it is the part newcomers get wrong. Agent pods are disposable and start knowing nothing. What persists is the code graph they read and the Task journal they write, so the pod that finishes your work is usually not the pod that started it.
What that run did not show¶
One issue exercises one path through the loop. These are the parts #621 had no occasion to use.
-
A code graph the agents read from
The ingester walks each repository and pushes a code graph into LightRAG and Neo4j. Agents query it for context instead of re-reading files cold, which is what a pod that starts knowing nothing needs.
-
Work nobody filed
A periodic scan of the codebase and the knowledge graph proposes its own improvements, from new features to tech-debt and CI health fixes. #621 started from an alert; a Task can also start from something tatara noticed on its own.
-
One Task across several repositories
A single Task can span repositories and open a pull request in each, and related issues can be grouped into one agent run behind one combined change. #621 touched one repository, which is the easy case.
-
All of it is a CR
Six CRDs (
Project,Repository,Task,QueuedEvent,Issue,MergeRequest) managed by a controller-runtime operator. The state machine that run walked iskubectl get task, not a dashboard you have to be given access to. -
Every deploy is a pull request
"The cluster ran it" above is a helmfile pull request merged on an in-cluster ARC runner, which is the only way anything reaches the cluster. No
kubectl set-image, no surprise state drift.
Who tatara is for¶
You want autonomous incident response, self-improving infrastructure, and a reproducible agent-execution platform on your existing Kubernetes cluster.
Tatara gives you: a Kubernetes operator with Helm chart, OIDC-gated APIs, Prometheus metrics on every component, GitOps-only deploys, and Grafana alert rules that fire directly into an incident-investigation agent.
Start with Installation and Observability.
Nothing gets written until a person you named comments on the issue. maintainerLogins is empty by default and an empty list approves nothing, so an unconfigured Project reconciles cleanly and produces no code at all.
What comes back is a pull request. A separate review pod, with no memory of having written the code, reviews it, and the operator merges only on an accepted verdict, at the exact commit that was reviewed, with CI green. That round earns its keep. On the run above, the reviewer followed a status field the new code wrote out of the diff and into the state machine that reads it, and found the case where a merged pull request would be marked closed and somebody else's finished work rejected in public. The agent took that finding, declined half of another one with its reasons, and both exchanges are on the thread with a timestamp. No agent merged any of it and none could have: the tool set an agent is given contains no merge action, so the merge is the operator's own.
Read The Big Picture and Workflows.
You want to understand the system deeply before adopting it. You care about the trust model, the prompt-injection surface, the CRD API, and how conversation persistence works.
Start with Architecture, the CRD Reference, and Security.
What tatara is not¶
- Not a general-purpose CI system. Tatara orchestrates agent turns, not arbitrary pipelines.
- Not a hosted service. You deploy it to your own Kubernetes cluster and connect it to your GitHub/GitLab organization.
- Not a monolith. Nine independent component repos, each with its own Helm chart, CI, and release lifecycle.
Components at a glance¶
Now that you know what a run looks like, here are the pieces that carry it.
graph LR
A[GitHub / GitLab] -->|webhooks| B[tatara-operator]
B -->|spawns| C[tatara-claude-code-wrapper pod]
C -->|MCP| D[tatara-cli]
D -->|REST| E[tatara-memory]
E --> F[(LightRAG + Neo4j)]
E --> G[(Postgres / CNPG)]
B -->|ingests repos| H[tatara-memory-repo-ingester]
H --> E
I[Grafana alerts] -->|webhook| B
B -->|GitOps| J[tatara-helmfile]
J -->|deploys| BLicense¶
GNU AGPLv3. See LICENSE.