How I run an Attio implementation business on Claude Code

Most of what an Attio implementation business does is not mysterious. A discovery call. A proposed data model. A migration. Pipelines that match how the team sells. A set of automations. A handful of agents. Training. Then a monthly cleanup so the workspace does not rot.

Write that list down and a pattern shows up. Almost none of it is novel. It is the same shapes of work, repeated for each customer, with the details changed. That is exactly the kind of work a good system should absorb.

My system is Claude Code. Not as a coding tool. As the place the business actually runs.

Claude Code is the operating system, not an editor

Most people meet Claude Code as a thing that writes code in a terminal. That is the smallest version of it.

What it actually is: an agent that can read and write files, run commands, reach other tools through MCP, hold instructions in memory, and be extended with skills. None of that is specific to code. A services business is files, instructions, repeatable procedures, and connections to outside tools. Same shape.

So I stopped treating Claude Code as an editor and started treating it as the company's operating system. Every part of delivery lives inside it.

Discovery becomes a document, then a diagram

A discovery call produces a transcript. On its own a transcript is a wall of text.

I have a skill that takes a customer's name and pulls everything I have on them: the call transcript, the email history, anything they sent through a form. It reads all of it, does light web research on the company, and turns it into a proposed Attio implementation. Objects, attributes, relationships, lists, automations, integrations, a migration plan. Then it renders that as a FigJam board the customer can actually look at.

The work that used to be an afternoon of staring at notes and drawing boxes is now a request. I still read every line of the output and fix what the model got wrong about the business. But it starts me at a draft instead of a blank page.

The build runs through Claude Code and the Attio API

When a customer signs, the build is migration, data model, and automation.

Claude Code talks to Attio two ways. The MCP connector handles reads and record work: search the workspace, pull records, check what is already there. The REST API, with the customer's key, handles what the connector cannot: creating objects, attributes, statuses, and the schema itself.

So a data model I designed in FigJam becomes a sequence Claude Code executes against the real workspace. A migration becomes a scripted, checked process instead of a careful afternoon of CSV imports. I am still the one deciding what the model should be. Claude Code does the hundred small mechanical steps that turn that decision into a live workspace.

Every repeatable task becomes a skill

This is the part that compounds.

In Claude Code, a skill is a markdown file that teaches the agent how to do one specific job. The first time I do a task, I do it by hand. The second time, I write it down as a skill. From then on the task is a sentence, not an afternoon.

The business now runs on a stack of these. A skill for turning a discovery call into a data model. A skill for the prospecting workflow. A skill for re-scraping the Attio expert directory. A skill for a weekly workspace audit. A skill that keeps my customer records in sync between a local folder and Notion, so I never have to ask it to.

Each one is small. Together they are the difference between a business that depends on me remembering how I did something three months ago and a business that has its procedures written down and executable.

The agents I ship run the same way

The skills I install in every customer workspace are built the same way as my internal ones. They are markdown skills. The difference is where they run.

I do not host them. There is no server with my name on it, no API key I am holding, no usage I am marking up. Each agent is a skill that runs on the customer's own Claude Code subscription, scheduled to wake up on its own. I wrote a separate piece on why that architecture matters: how I deploy AI agents without hosting a server. The short version is that it keeps me from becoming infrastructure the customer cannot fire without losing what they paid for.

The point here is narrower. The same unit, a skill, is how I do my own work and how I deliver the customer's. There is one way of working, not two.

The business has almost no infrastructure

Add it up and something is missing.

There is no server. There is no separate project-management tool, no internal app I am paying for and maintaining. The data model designer, the migration runner, the audit, the customer sync, the agents: all of it is markdown files and an agent that reads them. The expensive, fragile parts of a normal services business, the hosted code and the operations work that keeps it alive, are not there.

That is not a trick. It is a consequence of using skills as the unit of work. A skill is text. Text does not need a server, does not go down at 2am, and does not need a redeploy. The runtime is Claude Code itself, and I already pay for that.

A small version of this business would normally drown in tooling and operations. It does not, because there is barely any.

What still happens at human speed

I want to be honest about the limits, because the version of this story where a model runs the company is not true.

I run the discovery call. A model can summarize a transcript. It cannot hear what a founder is not saying, or notice that the real problem is two people on the team disagree about how they sell.

I make the design decisions. The skill proposes a data model. Whether that model is right for how a specific firm operates is a judgment call, and it is mine.

I own the relationship. The customer hired a person. When something is wrong, they get a person, not a queue.

And the team is part of this. I am not solo anymore. Claude Code does not replace the people I work with. It removes the work that should never have needed a person, so the people can spend their time on the parts that do.

What it changes

The reason this matters is not that it is clever. It is what it does to the math of a small services business.

A normal implementation agency scales by hiring. More customers, more delivery work, more people doing the repeatable parts. The repeatable parts are most of the work, so headcount climbs fast and the margin does not.

When the repeatable parts live in skills, that curve bends. A new customer is mostly the same skills run again, plus the human judgment only a person can add. The business can take on more work without the cost of that work climbing at the same rate. The humans stay on the calls, the design, and the relationship, which is where they were always worth the most.

I did not set out to build the business this way. I set out to use a good tool, noticed the repeatable work piling up, and started writing it down. The system is the accumulated result of that habit.

If you run a services business, that is the part worth copying. Not my specific skills. The habit of doing a task once by hand, then never doing it from scratch again.