There's a management concept that's been failing companies for decades, and nobody talks about it directly. The org chart. Not the idea that roles should exist, or that authority should be defined — those are fine. The chart itself. The two-dimensional diagram that flattens a complex system of decisions, dependencies, and judgment calls into a box-and-line hierarchy.
The chart doesn't capture what actually runs an organization. It captures reporting relationships. Those are not the same thing.
I've been thinking about this since we crossed 28 agents at Vibe Tokens. Not because the number is meaningful on its own, but because of what building that many agents forced me to understand about what "a role" actually is.
What a role actually contains
When you hire a person into a role, you hand them a job description. Maybe it's thorough, maybe it's three bullet points drafted in a hurry. Either way, it's incomplete. The rest of what the role requires — the judgment calls, the escalation thresholds, the implicit authority to make certain decisions without asking — gets transmitted through culture, through onboarding, through watching how other people behave.
A Claude agent can't absorb culture through osmosis. There's no hallway conversation, no passive observation of how the VP handles ambiguous situations. Every constraint, every decision boundary, every scope clarification has to be written down.
That's not a limitation. That's the work.
When I built out Vibe Tokens' Executive department — the agents responsible for company-level decisions, cross-department coordination, final calls on strategy — I had to answer questions I'd never made explicit before. What does it actually mean to have "authority" over a decision? When does an agent escalate versus act? What information does this role need to function, and what information should it actively not have, because having it would bias its outputs in the wrong direction?
Every agent at Vibe Tokens lives in a Markdown file. That file contains scope, decision authority, voice, rules, and the MCP connections it's allowed to use. The file is the role. Not a description of the role. The operational definition of it.
When you write it that way — when you have to make it concrete enough that an agent can execute reliably — you discover how much organizational dysfunction lives in the gaps between what's written and what's understood. Most human organizations run on those gaps. They're filled by institutional knowledge, by personality, by whoever has the most political capital in the room.
Agent organizations can't run on gaps. The gaps just produce errors.
The department structure that emerged
Seven departments. Twenty-eight agents. The breakdown matters:
Executive handles company-level coordination, client escalations, and the decisions that affect multiple departments simultaneously. One agent, tight scope, high authority ceiling.
Operations manages internal process — the systems that keep other systems running. Thinks in workflows and failure modes.
BizDev owns the client-facing surface. Proposals, relationship context, follow-up sequences. Connected to Gmail and GCal via MCP so it can orient itself to actual calendar state and communication history before acting.
Marketing and Content are split intentionally. Marketing thinks in positioning and audience signals. Content executes on specific formats. Separating them forced me to define where positioning decisions get made versus where production decisions get made — a distinction most organizations blur until it causes conflict.
Design connects to Figma via MCP. It can inspect actual design state, not just talk about design abstractly.
Development is the most complex department. Multiple agents, Claude Code as the execution layer, subagents spinning up in isolated git worktrees for parallel delivery. Context7 feeding live documentation so agents aren't building against stale API patterns. Playwright for browser-state inspection when integration work requires it.
The org chart version of this looks like a normal company. The actual structure is a set of Markdown files, MCP server permissions, and decision authority definitions that took months to get right and are still being refined.
Where the architecture breaks, and what that reveals
I want to be honest about where this falls down, because the places it breaks are instructive.
The hardest problem isn't agent capability. Sonnet 4.6 is genuinely impressive — the 1M token context window in beta means our most complex agents, the ones carrying full org context and active project state, have room we haven't begun to use. The capability ceiling isn't what I run into.
What I run into is information architecture.
An agent can only act on what's in its context. If the context is wrong, or stale, or incomplete, the output is wrong — confidently, fluently wrong. This is why Context7 sitting at the top of the MCP registry makes sense to me. The people who've gotten past "this is impressive" and into "this is operational" have discovered that stale context is the first thing that breaks reliability. Context7 solves it for documentation. We solve it for organizational state by routing key agents through Notion and Gmail MCP connections that pull current reality before execution.
But there's a second problem that's harder: organizational memory across sessions.
Human employees remember things. They carry context from last Tuesday's conversation into this Thursday's decision. Right now, our agents don't. Every session, they're reconstructing their understanding of current state from whatever's been persisted to Notion, whatever's in the project files, whatever the role definition tells them about standing patterns. It works. But it's not the same as continuity.
The MCP 2026 roadmap — stateful sessions, proper auth, rate limiting at scale — is interesting to me for exactly this reason. Stateful sessions mean an agent's working context could persist across the interaction boundary. That's not a small change. That's the difference between an agent that knows what happened yesterday and one that has to be told every time.
When that lands, the architecture I've built will need to be rethought. Some of what we currently persist to Notion as a workaround will become unnecessary. Some of what we route through explicit context injection will happen automatically. And some of what we've accepted as a constraint — the fact that continuity requires human curation — will just stop being a constraint.
What the /loop command changes about this
The recent Claude Code release that mattered most to me wasn't Computer Use, even with its 16 million views. It was /loop.
Background cron-style workers. PR reviews, deployment monitoring, automated test runs running without a human in the seat. Combine it with --channels forwarding approval prompts to your phone, and you have something closer to async supervision than active management.
Here's the operational translation: right now, about fifteen of our 28 agents approximate this already. They run, they log, they flag exceptions. But they still require more active human time than the work actually warrants. Not because the decisions are hard — because the infrastructure for genuinely background execution didn't exist natively. We've been building workarounds.
/loop removes the workaround layer. And when you remove workarounds, you see the architecture that was hiding underneath them.
What I think becomes clear: the human role in an agent-native organization isn't execution. It's not even management in the traditional sense. It's role definition and exception handling. You write the Markdown file. You calibrate the decision authority. You set the MCP permissions. Then you supervise exceptions — the edge cases the agent flags because they're outside its defined scope.
Gloria Mark's research on context-switching — the 23-minute recovery cost every time your attention gets pulled — argues for making those exceptions rare. Not because humans are fragile, but because deep work and exception triage are competing for the same cognitive resource. Every time an agent surfaces something it should have been able to handle, that's a role definition that wasn't tight enough.
That's the work I'm actually doing most of the time now. Not building features. Tightening definitions.
The thing the org chart couldn't tell you
Box-and-line hierarchies were always a simplification. They showed authority without showing information flow. They showed reporting relationships without showing how decisions actually got made. The consultants who drew them knew this. They drew them anyway because the alternative — capturing the real complexity of how an organization actually operates — wasn't legible on a slide.
Agent org structures force the legibility. Every dependency has to be explicit, because there's no implicit channel for it. Every decision boundary has to be defined, because the agent will hit the boundary and either act wrong or fail to act at all.
The interesting thing is what this does to organizational design as a discipline. When you have to write down, in a Markdown file, exactly what a role is authorized to decide — you start asking questions that most companies never actually answer. Not "who's responsible for this?" but "at what threshold does this decision require escalation?" Not "who owns marketing?" but "where does positioning authority end and production authority begin?"
Those are hard questions. They were always hard. It's just that before agents, you could avoid answering them precisely.
Now you can't.
I wonder sometimes what it would look like if a traditional company — one built on human org charts and institutional knowledge — tried to do what we've done at Vibe Tokens. Not replace their people with agents. But write the Markdown files. Define the scope and authority for every role, explicitly, the way you'd have to if an agent were going to execute it.
I suspect the exercise would reveal more organizational dysfunction than the agents would.
