When agents become teammates

Arnav dropped it into a Slack thread at 10pm. At 10:02 I pinged it asking for the feature I always wanted. It shipped it in 2 mins and gave me a link to the preview. Zaria asked for a UX change. Marcus took a look at the code and suggested a better way to architect it. PR open at 10:02. Entire team jumping in by 10:15. Shipped by 10:20. We lovingly called the engineering agent we had made Coworker.

A day earlier that thread would have been two meetings. One to line up product and design, one to quickly chat eng. Then someone would have shipped it solo; others would guess the thought process when they read the PR. Instead we sorted it out in public while the work was always moving forward. It felt multiplayer in a new way. An entirely new way for teams to collab, mediated through an agent.

When Marcus and I started Create, the company behind Anything and Skydive, we named our codebase Escher. We both loved Drawing Hands: two hands on a page, each one drawing the other. A picture making itself. That was what we thought code gen could become one day. In the limit, if you could generate code, you could build companies that build themselves.

So of course, demo feature shipped, our next step was to make Coworker self improving. So we hooked it up to its own production logs. It read the errors, found the code path, and started opening its own PRs to improve itself. Nobody asked it to.

That was the moment the loop closed. The codebase was drawing its own hands, and the whole company could interact with it in a Slack thread.

Over the next few weeks, it learned how we like to ship product. Who to pay attention to about what. We gave it more tools and more access. It took a week or two for an eng each time, but it always felt worth it. It was the company building itself.

Then everyone wanted their own

Coworker was great for a few weeks. Then people started asking it for things it had no business answering.

Dylan runs support. He wanted Coworker’s code ability plus everything he knows: Intercom history, the docs, how mobile builds break, and a hard rule about when a refund is his call and not the agent’s. Zaria wanted design taste that stays inside our brand rules. GTM wanted launch copy, customer language, and the numbers behind a campaign.

The first instinct was to make Coworker bigger. More access, more context, one agent for everyone. That was the trap. Dylan didn’t want the god of all things company. He wanted something perfect at the job he gave it. Like Coworker was when all it did was eng.

Same body, different person

So we stopped growing one agent. Instead we made a platform that makes making any AI coworker easier. Every agent now starts with the same setup: infra to spin up their own computer, easy ways to add apps as any tools, credentials for its job and nothing else, memory of what it has learned, easy ways to run routines, and its own identity so it can talk to you in all the places you’d like without rebuilding a really great Slack, email, or iMessage experience for each additional agent.

That part is standard issue. The part that makes a teammate yours is the part we can’t ship. The job you give it. The standard you hold it to. The time you spend training it. The memories it picks up along the way that makes it even better the next time.

Dylan went first and rebuilt Coworker as Emma. Emma is Dylan’s support agent. Otis is Marcus’s engineering project manager. Indi is how GTM thinks about paid spend. Same body every time. But completely different personas, goals, and outcomes.

The fun part is these agents are still quite multiplayer (even people beyond the creator ping any agent in Slack). They’re no longer managed by the eng team, but still just as powerful. It’s just that they’re made and trained by the person who knows the job best. So they get really really good at their job, faster than anyone could “build them”.

And then they start working together

The team starts weighing in. But it’s no longer humans only on the thread.

Emma (support) notes an urgent spike in customer issues might suggest a production outage. Canary (production monitoring) and Grace (bug investigator) weigh in. Emma communicates with the marketing agent who owns email tone and targeting. And a human says yea that seems right, and the whirlwind of activity continues.

The humans design the agents, and then the agents move the company.

Give it 6 months and Emma will pull in design agents, who will pull in eng agents, who will pull in QA agents to validate, who will pull marketing agents. None of that will be a traditional meeting. It will just get done. We set the goals, imbue them with our judgement and taste, and that’s the reason why they’re even valuable at all.

We named the codebase after a picture that draws itself. The code mostly does write itself now. What’s left is teaching it what we know, and that’s the whole job.