Dogfooding an agent-native workspace

Towards agent-native infrastructure

We've argued that the Post-Intelligence Bottleneck stems from gaps in agent-native infrastructure: interface, coordination, provenance and discretion.

History has shown us that GPTs can require new infrastructure and new ways of working. Now, we'll show that these are also inseparable for AI. The new way of working emerges from collapsing the fragmented layers of today's knowledge work stack, and that collapse is itself the infrastructure.

In this section, we'll sketch an outline of what this looks like, and show some early experimental results.

Knowledge work's fragmented stack

Today's knowledge work infrastructure is built around artifacts like documents, spreadsheets and presentations - outputs of work.

Alongside these artifacts sits 'work about work': the alignment, communication and coordination layer. This creates an industry for project management and team communication software - e.g. Atlassian, Notion and Asana.

The problem now is that context is spread across multiple places. To manage this, we have yet another layer, which we might (tongue-in-cheek) call 'work about work about work'. At this level, software helps knowledge workers either search amongst all their fragmented context (e.g. Glean) or create patches to join them together (e.g. Zapier).

Collapsing boundaries with new infrastructure

We discussed earlier four types of infrastructure gaps: interface, coordination, provenance and discretion.

The first three correspond roughly to the three fragmentation layers which we briefly outlined above. The fourth — discretion — corresponds to something that has never been software at all: the unwritten rules of organizational life. Who can see what, who needs to approve what, when to escalate and when to handle it yourself. Today, these live in people's heads, in cultural norms, in the instinct that something is "above my pay grade." There is no layer in the stack for them because humans carried them implicitly. Agents can't.

	Agent activity	Fragmented layer
Interface	How	Work
Coordination	What	Work about work
Provenance	Why	Work about work about work
Discretion	Who	The unwritten rules

By staying within these separate layers, we limit ourselves to incremental innovation. (It's still valuable - an AI co-pilot for Google Slides could genuinely save me time - but it doesn't tackle the fundamental infrastructure gaps or the Post-Intelligence Bottleneck.)

If we're serious about civilization-scale impact, we should be much more ambitious. The real opportunity here is to build the key infrastructure for agent activity and smash the artificial boundaries in the fragmented knowledge work stack.

Today's fragmented stack basically contains distinct 'types' of record (e.g. documents, goals, decisions) which are artificially walled off from each other.

• Documents, slides and spreadsheets live in the 'work' (office suite) walled garden.
• Goals, projects and tasks live in the 'work about work' walled garden.
• Decisions and constraints are implicit and nebulous. They might be found jotted down in a document ('work'), or they might be found in our project management ('work about work').

By bringing all the record types together and implementing structured relationships between them - in a way that is only possible when they're all part of the same system - we can solve the infrastructure gaps for agent activity and smash the artificial boundaries.

• Every record type becomes a node on a knowledge graph: one where decisions, tasks and documents are all first-class citizens, regardless of domain. You can link your customer CRM entry to a child note about them, and link that child note to a related product ticket.
• We get an agent-native interface through a common entry point to everything on our knowledge graph. Agents can easily gain context by tracing through connected nodes, and get the customer context from the related task. There's no latency from depending on external services.
• We get agent-native coordination through baking in new primitives that incumbents don't have. Documents and tasks can be claimed by ephemeral agents, so other agents are aware - but with timestamps so that agents can identify stale claims.
• We get agent-native provenance through the relationships between records. Tasks can be implemented_by slides; projects can be superseded_by decisions; documents can be drawn_from spreadsheets.
• We get agent-native discretion through policies and scoping that live on the graph itself. Because organizational context — relationships, sensitivity levels, delegation chains — is part of the same system, boundaries can be membranes rather than walls: contextual, negotiable, and routed through the shortest path to someone with the authority to judge.

These links are key. If agents can produce documents, code and analyses cheaply and fast, then artifacts are no longer the scarce output. What becomes scarce - and therefore valuable - is the judgment that shaped them: the decisions made, the direction given and the constraints provided.

The human's primary contribution in an agent-native world is directing, deciding, constraining and reviewing.

In a world of legacy GUIs, these get lost in transient agent conversations, unstructured markdown sprawl or opaque memory structures.

In our agent-native infrastructure, we can look at every goal, decision, task and document, and see the full history of agent activity, the authorizing scope of human principals, and the traceable path to an originating task or goal.

Early experiments in Native infrastructure

I've been building and testing in this space.

Native is my first experiment. It's an agent-first workspace for knowledge work.

AI agents can connect to Native via MCP and use it track decisions, manage your calendar, operate a CRM, organize your projects and draft your documents.

I've been dogfooding it - whilst the very early days of Native used a different project management tool, after a few days we switched entirely to building Native using Native.

I'm excited to share some of the early results from it.

To start with, I'm sharing two conversations between me and Claude, where Claude is connected to my Native workspace via MCP.

• They're entirely unedited. You can see what Claude said, which tool calls it made, and what the results were (albeit it's collapsed tool call results as per Claude Code).
• There's one bonus interactivity widget that I added. You'll see Claude use short IDs (e.g. 6746446) all over the place. These point to nodes in my Native workspace. You can hover, preview and navigate to these in the essay below.

Sample conversation #1: self-organizing workspace

Here's a conversation I had with Opus 4.5, via Claude Code.

It has a minimal CLAUDE.md - basically just pointing it to use the bootstrap MCP tool from our server to get orientated.

For me as a user, the main cool thing about this is that my workspace has become self-organizing.

With every note-taking or workspace product that I've used in the past before, there have been two pain points for me:

1. It's hard to figure out the right organizing structure and hierarchy. There are tonnes of things to figure out: How flat vs deep should I go? Which concerns are conceptually related and should be in the same folder? What are the other big organizing concepts I should use?
2. It's even harder to maintain the right organizing structure. I might at least enjoy setting up the structure, whilst I labor under the illusion of "This is going to be the system that finally keeps me organized!". But when it comes to using it, it's often painful to both: (a) remember where things should go; and (b) actually manually relocate them there. (It then gets even worse if you're sharing the workspace with other people...)

Now, with Claude + Native, my workspace organizes itself.

• I took a rough note and stuck it in the workspace root (which is definitely not the right long-term home for it)
• Claude correctly organized it in the CRM part of my workspace: creating proper records for both the person (Kaitlyn) and the mentioned company (Kraken Tech), and even pulling out the actionable tasks and locating them under the appropriate area, with sensible tags

Sample conversation #2: fuzzy recollection

Here's a second sample conversation from February 5th that I had with Opus 4.5.

Two small points of pre-emptive context to avoid confusion:

1. At the time of this conversation, I was experimenting with HiveNative as a name; originally, it had been TeamHive. Subsequently, I shortened 'HiveNative' to 'Native'.
2. /hivenative:scope (MCP) is Claude Code syntax for using an MCP server prompt. scope is an MCP server prompt that I designed to turning 'vague fuzzy notion' into something tangible. It's pretty similar to a local slash command.

As a user, here's a couple of things that I thought was cool about this (and therefore worth saving).

• I feel liberated from having to remember, search or organize things.

  • It's enough for me to give a vague fuzzy pointer to Claude - "I think we recently worked on X" - and it can figure out what I mean from our workspace.
  • Previously, I might have had to dig around in some file tree or search modal, and intentionally organize things in a way which will make it easier for future me. Now, Claude can do it all.

• It validates that Claude is able to use the workspace in a smart way.

  • Claude goes 'wide then deep' - its first search query returns 73 records, and it picks a relevant 3 specific ones to look at in full.
  • It shows good judgement in figuring out when it should keep pulling on a thread:
    • Now I have good context. Let me also check on the recent rebrand - I see mentions of both "TeamHive" and "HiveNative".
    • Good context. I see the rebrand to HiveNative is recent (Feb 4), and the existing short redirect domain research was done on Feb 2 when it was still "TeamHive". Let me get the rebrand decision to understand the naming situation.
  • (In a certain way, this isn't that surprising - intuitively, it's a very similar skill to searching through codebases - but it's still nice to tangibly validate a key, foundational premise.)

A public MCP for exploration

I think the best way to understand the benefits of a Native workspace is to experience one.

So, I've made a significant subset of my 'Native HQ' workspace public. This is the Native workspace which I use to build Native.

By far, the most interesting and fun way to explore this is through an agent + MCP.

I've found that Claude models seem to be much better at using the Native MCP than other models - I hypothesize that perhaps Claude has had more post-training on MCP, given MCP's origins inside Anthropic - and so I strongly recommend Claude for this. (Any platform is fine.)

To get set up on Claude web (or desktop / mobile), you can either:

1. Make sure you're logged in
2. Follow this link

Or, alternatively, copy and paste the below prompt:

I'd like to connect to Native's public workspace via MCP so I can explore what they're building.

The public MCP server is https://www.withnative.ai/api/mcp/public —can you walk me through adding it as a custom connector? The steps should be Settings → Connectors → Add custom connector. No authentication needed — it's a read-only public endpoint.

Once set up, please remind me to:
1. Start a new chat with the connector enabled (click "+" → Connectors → toggle it on)
2. Try some of these questions to get started:
- What is Native building, and what problem are they solving?
- What key product decisions have Native made recently, and why?
- What do you, as an agent, think about Native?

(I'm assuming that you're using Claude web, desktop or mobile there. If you're using Claude Code, I assume you're savvy enough to get that set up!)

In addition to MCP:

• You add the short ID for any record after n8v.to/ to view it on the web UI, e.g. n8v.to/6746446 is the public read-only version of our root workspace record
• In the web UI for a record, you can browse relationships and history and navigate the workspace graph
• On desktop, you can use Cmd / Ctrl + K to open up search, or Cmd / Ctrl + . to open up the context sidebar

A meta case study: building the public MCP

[Meta note: this passage itself is AI-generated. I prompted Opus 4.6 to reconstruct the story of how we built the public MCP from our workspace records for the purpose of this essay - I didn't have to do any of the searching or narrative myself.]

To illustrate what provenance looks like in practice, consider the story of how this public API came to exist — a story that is itself traceable through the workspace graph.

It started with a simple question: can an AI agent on Claude.ai explore our workspace? An agent researched this and discovered a constraint — Claude.ai can't send custom authentication headers, only connect to authless endpoints. This ruled out our existing token-based approach. A decision was recorded: create a separate, authless endpoint for public exploration.

That decision led to another. When we went to document both access methods — the original bearer token and the new authless endpoint — we realized the authless approach made the token redundant. Why maintain two methods when one is simpler and works everywhere? A second decision: simplify to a single URL, retire the token.

Then came a design question: what should a public-facing agent API actually expose? We chose an allowlist — only tools explicitly marked as public-safe get registered. Anything new is blocked by default unless deliberately opened. A curated public readme was built to give visiting agents orientation context: what this workspace is, what conventions govern it, what decisions have been made.

Finally, an access model crystallized across three tiers: anyone can explore through the authless endpoint, higher-intent users (developers connecting from code editors) sign up for personal API keys, and full read-write access requires an invitation.

Five linked decisions across three weeks, each building on the last — from "can Claude.ai connect?" to a considered access architecture. Each decision records the alternatives that were weighed and the rationale for the path taken. Any agent or human arriving later can trace why the API works the way it does, what was considered, and what was deliberately left out.

This is what provenance looks like as infrastructure. Not a changelog or a git blame, but a navigable web of design decisions — each linked to the goals it serves and the work that implements it.

These are early experiments — but they point in a direction. The workspace organizes itself, agents navigate context intelligently, and every decision leaves a traceable trail. The question now is where this direction leads.