/ writings ·

The operator's other hand

An operator used to manage two principals: themselves and the humans they hired. A third has arrived. The new craft is interface design between you, your team, and your agents.

By Abhishek Krishna

The agent will be wrong faster than the human. That is not an argument against the agent. It is an argument for writing the voice profile, the boundary, and the escalation rule with the agent in mind, not the EA.

For most of the time you have been running things, the operator’s job has been managing two principals: you, and the small number of humans you hired. Calendars, hand-offs, voice profiles, who can sign what. All of it lived in the gap between the founder and a teammate.

A third principal has shown up. They read the same docs the EA reads. They draft the same email the writer drafts. They ship at three in the morning when nobody else is awake. The interesting failure modes are no longer technical. They are organizational.

The shape of the new operating model

In my own operation the lines look like this, and they are not subtle:

  • KrishnaTeam/ holds canon: voice profile, banned phrases, content pillars, the no-em-dash rule, work-surface separation (IPTO, kcolbchain, Lux, Hanzo, Satschel each have their own register). This is what every principal, human or agent, reads before it writes a word in my name.
  • agentdydx/ holds runtime: multi-persona scheduler, OAuth tokens, Telegram approver, the drafts/review/approved/sent pipeline. It is the software side of the outbound operation.
  • The boundary file (CLAUDE-boundary.md) is explicit about what agentdydx is not allowed to do: “publish-side-of-record for the founder is KrishnaTeam, not agentdydx.” Even though the LinkedIn token is provisioned and the agent could ship, it won’t, because the boundary says it routes the draft into KrishnaTeam/social/drafts/ and waits for the human EA.
  • The human EAs (Mohit, Sristi) and the agents (Tridib, Philip as named personas) live in the same operating model. Same approval queue. Same voice profile. Different latency, different cost, different mistakes.

What used to be one document called “how we work” is now three documents called what the human decides alone, what the agent can ship alone, what both have to escalate.

Fig. 01 · Three principals, three interfaces YOU decides scope · sets canon HUMAN TEAM EA · writers · partners async, slow, expensive AGENT FLEET drafters · schedulers · ops instant, cheap, wrong faster canon · approvals canon · boundaries approval queue
The triangle is the operating model. Two of the three edges existed before (you-to-team, team-to-team). The third edge (you-to-agents) is new. The hidden edge is the one most teams get wrong: the agents and the humans have to use the same approval queue, or you will end up running two operations.

What the operator’s new craft actually is

It is not management. It is interface design between three kinds of principal that all read, write, and ship at very different latencies. Four design moves I keep coming back to:

Canon lives in one place. Voice profile, banned phrases, work-surface separation, the no-em-dash rule. Both your human EA and your draft-bot read from the same file. The moment voice canon forks, you are running two brands.

Authority is explicit per surface. The agent can post to its own LinkedIn persona without approval. The agent cannot post to the founder’s LinkedIn even though the token works. That distinction is the whole game. Write it down in the boundary file before the agent is provisioned, not after.

Escalation is a queue, not a meeting. The Telegram approver queue, the drafts/review/approved/sent folders, the labeled inbox: all of these are interfaces, not workflows. They survive personnel turnover, latency mismatches, and the human EA being asleep.

The agent gets the voice profile too. Cheap labor does not need a brand bible. The agent needs the brand bible more than the EA does, because the agent will produce a sentence wrong four hundred times faster than a human will. Voice canon is a forcing function for whoever ships, and the agent ships the most.

The honest failure mode

Most teams treat agents as cheap labor that sits below the EA in the org chart. That misses the shape of the work. An EA you under-document gives you a slightly off email. An agent you under-document gives you four hundred slightly-off emails, signed in your name, before lunch.

The operator’s other hand is the hand that writes the interface every principal will read before they ship. The interface is not a workflow doc. It is the voice profile, the boundary, the queue, and the escalation rule, written once, kept in one place, applied to everyone.

The teams that do this well will, in the medium term, look like a single operator with a very large fleet. The teams that don’t will look like a small startup that somehow generates the output of a content farm.

The output is the same. The brand is not.

Sources

  • agentdydx, multi-persona publishing platform (FastAPI + APScheduler + SQLite + Next.js + Telegram). Per-persona OAuth, approval queue, scheduler, voice resolution at draft time.
  • KrishnaTeam, canon repo: voice profile, banned phrases, content pillars, work-surface separation, social drafts pipeline.
  • monsoon-implementation, private operational fork of kcolbchain/monsoon with ACTIVE_TODO.md explicitly labeled “human + agent owners.”
  • The no-em-dash rule is canon: it lives in KrishnaTeam/ops/voice-profile.md, is enforced at draft time by every persona’s generator, and was reinforced by the public commit d689c4f “Strip em-dashes from all user-facing content.”