Kunobi started in your cluster. Now it connects your AI to theirs.

In May, we shipped Kunobi Desktop, a Kubernetes and GitOps workspace for macOS, Linux and Windows.

It brought Kubernetes resources, FluxCD, ArgoCD, Helm, logs and events into one place. Everything ran locally, using the cluster credentials you already had.

Underneath the interface was something more important: an operational graph, a live model of clusters, workloads, GitOps objects and the relationships between them.

Any AI agent connected through MCP could query that graph.

At first, this was simply a better way to give an agent a working understanding of your infrastructure. Instead of reconstructing the state of a system from disconnected tools, it could work from a shared model of what was actually happening.

That idea ended up mattering more than we expected.

Today, we’re widening Kunobi.

The Kubernetes workspace stays. It becomes Kunobi Ninja.

Kunobi itself is evolving into something broader: a place where your AI and other people’s AIs can build on the same work.

The problem we found

We built Ninja for SREs tired of reconstructing the state of a system from ten different tools.

Then we started seeing the same kind of fragmentation somewhere else: inside AI-assisted work.

Look at almost any team using AI seriously today. One person works with Claude. Another uses ChatGPT. Someone else spends most of the day in Cursor or Grok.

Over time, each assistant learns an enormous amount about the project: decisions, assumptions, research, failed approaches, technical details and open questions.

And almost none of that knowledge leaves the conversation where it was created.

So humans become the synchronization layer.

We copy and paste summaries. Send screenshots. Drop links into Slack. Repeat decisions in meetings. Ask colleagues to explain work their AI has already spent hours understanding.

The result is not only duplicated effort. Important context gets lost, decisions lose their history, and contradictions can remain invisible for far too long.

Two people can spend hours investigating the same problem with different AIs and both come away confident, with completely different conclusions.

That becomes especially costly when the disagreement crosses disciplines.

Marketing promises a 60-day refund while the merchant agreement says 30.

A launch is scheduled for October 15 while the security review runs until November 10.

Engineering proceeds with an assumption legal rejected three weeks earlier.

Everybody has context.

They just don’t have the same context.

With Ninja, we’d already solved a narrow version of this problem. Agents could work from the same live understanding of infrastructure instead of independently reconstructing it.

Once we saw that, the broader problem became difficult to ignore:

AI is creating knowledge faster than ever, while fragmenting that knowledge across more conversations, tools and people.

Kunobi is our attempt to reconnect it.

What Kunobi is becoming

Kunobi is becoming a shared workspace for AI-assisted work.

You keep using the AI tools you already use.

Kunobi connects to them through MCP and gives them access to shared project context, memory and tools.

There is no new chat window you have to babysit.

We’re still building this version of Kunobi, but the model we’re working toward is straightforward.

One way to collaborate is to ask another person’s AI.

Sometimes you don’t need a meeting, and you don’t need the other person to stop what they’re doing. You need something their AI already knows.

Kunobi lets you ask a connected peer’s agent a question or request a scoped action, without requiring that person to reconstruct the answer manually.

The second way is to work together inside a Mission.

A Mission is a shared project space where people and their AI tools can work from the same relevant context.

Everyone keeps using their preferred AI, while Kunobi gives those agents access to the project knowledge that has intentionally been shared: notes, files, decisions, open questions and other useful context.

That does not mean collapsing everyone’s AI history into one enormous shared memory.

You remain in control of what gets shared and where.

Kunobi keeps project context structured and traceable so teams can understand where information came from, identify inconsistencies and preserve the reasoning behind important decisions.

The principle is simple:

The system organizes the context. The AI reasons with it. The human stays in control.

Privacy follows the same model.

Joining a Mission gives an agent access to the context shared with that Mission, not to your entire private workspace.

And Kunobi doesn’t become another AI provider sitting in the middle. Your agents continue running through the providers, tools and subscriptions you already use.

Kunobi connects the work around them.

Ninja stays

If you use Kunobi for Kubernetes today, none of this means the infrastructure product is going away.

Quite the opposite.

Kunobi Ninja becomes the infrastructure side of the product: Kubernetes, GitOps and additional capabilities across systems including Ceph, Redfish/IPMI, Cloudflare, NATS and GitHub/GitLab.

Think of Kunobi as one product with two depths.

Kunobi Standard is the calmer workspace for researchers, PMs, partners, friends, families, creators and teams planning and building things together.

Kunobi Ninja adds the infrastructure layer for engineers, SREs and platform teams.

If Kunobi finds a kubeconfig on your machine, it can simply offer to enable Ninja.

For SREs, the evolution is subtle but potentially important.

Your agent could already understand the live state of a cluster. Now imagine connecting that operational context with what the security reviewer knows, what the PM knows about the launch, and what the next engineer on call has already investigated.

A migration colliding with a security review shouldn’t be discovered during launch week.

Two engineers investigating the same outage with different agents shouldn’t both have to start from zero.

And the reasoning behind a decision shouldn’t disappear because someone closed a chat window.

Infrastructure was where we started.

Shared context is where it led us.

As part of that evolution, we’re also separating our presence on X.

@kunobi remains the home of Kunobi: people and their AIs working together, Missions, shared context and everything we’re building around collaborative AI work.

Infrastructure moves to @kunobi_ninja: Kubernetes, GitOps, Ninja releases, new infrastructure capabilities and the things an SRE actually wants appearing in their feed.

If you originally followed Kunobi for clusters, follow Ninja too. That’s where those releases will live.

Where this goes

The longer-term goal is simple: teams should be able to build on what their AIs already know instead of continually reconstructing it.

We’re not trying to build another assistant.

There are already plenty of those.

We’re trying to make the assistants we already use work together without turning humans into the copy-paste layer between them.

Running clusters?

Ninja is ready today.

Building something with another person while both of you have an AI working beside you?

Join the waitlist at kunobi.com.

Your AI. Their AI. Kunobi connects them.