Not subscribed? Sign up to get it in your inbox every week.

An agent sends five emails a day on behalf of this newsletter, and on Saturdays it reviews its own work.

The agent is a Grok Bot, connected to my email. Its job is sponsor outreach: find companies that should be in front of this audience, write each one a specific message that frames their company the right way for a room full of operators, and send five a day. Every weekend it looks at how the week went (opens, replies, who ignored it) and brainstorms what to change. It has come back with ideas about who we should be targeting in the first place, how the pitch should be worded, and how long the emails should run. Some of those ideas were better than mine.

Five weeks ago this stopped being a developer's toy. xAI opened the Grok Bot beta on August 11: bots that share a computer of their own in the cloud, sign into your existing tools, and keep working after you step away. Two weeks later Instinct, founded by a 23-year-old, raised $250 million at a $2.5 billion valuation for an agent you text or call like a person. Last Tuesday Meta shipped Muse, free for most uses, inside WhatsApp. Town, founded by Plaid's former CTO, has run an email-native version since June for a user base that includes Australian plumbers, one of whom gets 300 emails a day. Google's Gemini Spark and Anthropic's cloud Cowork are the lab versions.

Underneath, these are the same class of system as Claude Code or Codex: a model in a loop with a computer, a set of logins, and a to-do list. OpenClaw proved the demand a year ago, an open-source agent you ran on your own Mac and talked to over WhatsApp, which collected close to 390,000 GitHub stars while Karpathy was telling people not to run it on their computers. The new wave moves the machine into the vendor's cloud and deletes the terminal. Sheel Mohnot, a venture investor, described Instinct in four words after 677 messages in five days: "OpenClaw for normal people." His better line was the second one: "ChatGPT/Claude still feel like assistants that you operate, but Instinct is an assistant you employ." That matches my experience exactly. I don't operate my outreach agent. I gave it a job and a cap, and I read its Saturday report.

The usual caveat applies with extra force. Instinct's first public week produced a bot that sent an email without approval, kept summarizing a user's Gmail after she disconnected it, and got phished by instructions inside an email. xAI's own FAQ says every bot on your account shares one cloud computer and every login, then adds a sentence worth framing: "Do not use separate Bots as a security boundary." Two weeks ago I wrote that your controls were built for people. My five-a-day cap is the control on my outreach agent, and it exists because I read that FAQ. Keep that thought; I'll come back to it. First, the part that lands on your product.

Ask what my two agents actually do with their cloud computers and their twenty-four hours, and the answer is that they use software. The outreach agent lives inside my email and whatever it needs to research a sponsor. The digest agent reads dozens of sites, papers, and feeds every week. Multiply that by everyone who is about to have one, and the picture is millions of agents logging into CRMs, banks, airlines, and your product, to do whatever your customer hired your product to do. Every one of those is a session with a user who has no eyes, infinite patience, and a referral from your customer.

There are two doors into your product, and the agents are using both. The front door is the browser. Grok Bot signs in with the user's own credentials and drives the real interface, and xAI aims it explicitly at platforms with "no clean API or MCP." Through this door the agent is a temp on day one: it reads the screen, guesses which button, and gets it mostly right. The side door is MCP, the Model Context Protocol, which is the standard way a product publishes a plug so an agent can operate it directly, with a menu of what the product can do written in plain words. Town lets users connect their own MCP servers, Gemini Spark announced MCP support at launch, and Cowork and ChatGPT both take them today. Through this door the agent can use your product like an expert. Provided you gave it a good menu.

The side door is already busy with developer agents. Atlassian handles more than five million MCP tool calls every working day, nearly a third of them creating or changing data, and 44% of the people behind those calls work outside software teams. Personal agents widen the population from engineers to anyone with WhatsApp, and every one of them shows up at your product through whichever door you left open.

Here is the reframe I want you to take away. When a customer's agent installs your MCP server, you have onboarded a new type of user, and its entire understanding of your product is what you wrote in that menu: the names of the actions, the descriptions, and whatever docs you attached. Microsoft's team that built one for its documentation put it in a line that belongs on the wall of every product org: "Your API is not an MCP tool." The descriptions work like a user manual for the agent, and in their words, "small wording changes can swing tool activation rates materially." Block, which has built more than sixty of these internally, says the descriptions are "treated as prompts for the LLM." You are writing instructions to a new employee, and the employee follows them literally.

Most of these menus are bad. A study of 856 tools across 103 public MCP servers found 97% of the descriptions had a quality problem and more than half never said what the tool was for. Rewriting the descriptions alone made agents measurably more successful at finishing tasks. The pattern behind the failures is the same one behind bad human onboarding: companies dumped their entire feature list on the new user and called it training.

Think about how you onboard a person. You hand a new hire three things: the tools (accounts and permissions), the playbook (how we do it here), and the reference (docs to look things up). Agents want the same three artifacts, and each one now has a name. MCP is the tools. Skills are the playbook, a written procedure the agent loads when a task matches it, in a format Anthropic released as an open standard that Cursor, Codex, Gemini, and Copilot all read. Docs served as clean text are the reference, and Stripe already ships all three together, installed with one command. The difference from human onboarding is the leverage. Onboarding a person happens once per person, over weeks, with a customer success manager. Onboarding an agent happens once per file, and every agent that installs the file is fully trained on day one. Better descriptions, a better playbook, and better docs translate directly into the agent getting the outcome you wanted inside your product, at a scale no onboarding team could staff.

If you sell software, your MCP server is a product with its own users, and it needs what your onboarding flow already has: an owner, analytics, and a design pass. Build it around the jobs customers hire you for, not around your feature list. Keep the menu short. Write each description as if it were the only manual the new hire got. Ship a playbook for your three most common workflows, and measure who is using it, because Atlassian only learned that 44% of its agent traffic came from non-software teams by looking. In July I told you to put "where is your MCP?" in your vendor evaluations. The sequel question is for your own product, and it is "how good is ours?"

The second place is inside your company, and my own setup is the example. My outreach agent holds my email login and acts on it fifty times a week. Somebody on your team did the same thing this month with a work account, and Grok Bot's whole premise is signing into the tools your team already uses. Your internal systems are getting agent users whether anyone approved it or not. The controls answer is the one from two weeks ago: scoped identity, hard caps, logs the agent can't edit. The product answer is the same as above. An internal tool with a decent MCP server gets used well by the employee's agent, and a tool without one gets clicked through by a temp working from screenshots.

Connect your own product's MCP server to Claude, ChatGPT, or one of the personal agents that takes MCP, and give it the three jobs your best customers hire the product for, phrased the way a customer would text them. In June the test was getting installed; this one is about the expert work that comes after. Watch three things: whether it picked the right action on the first try, how many steps the job took, and where it stopped to ask you something it should have known from a description. Then open the descriptions and read them as the only onboarding doc a new hire ever received. Most read like an API reference. Rewrite one this week and rerun the test.

No server at all ends the test at step one, and you've learned the same thing faster.

Everyone is about to employ an agent. Your MCP is how you onboard it.

Till next time,
Chris