Part 2 of a 5-part series on running an AI agent fleet inside a real company
Something changed in our secrets-management tooling, and nobody remembered doing it.
Normally that's a five-minute mystery: check the audit log, see who made the change, ask them. But our audit log said the change was made by me. And I genuinely could not say whether that was true. By then, several agents could act in systems under an identity that looked like mine. Did I change that setting, or did one of them? The audit trail could not tell me.
That is not an acceptable question to leave open in a real company.
At the end of Part 1: I Built This for Myself First, I had reached the obvious conclusion: this was too useful to keep to myself. I wanted the rest of the company to have the same leverage. Getting there meant answering two questions I hadn't taken seriously yet: where do these things run, and who are they? The first question took some expensive detours. The second one is the reason this post has its title.
The first distribution plan was a box on every desk
I did not begin with a grand theory of fleet infrastructure. I began with the most obvious advice on Twitter/X at the time: go buy a Mac Mini.
I pursued two versions of the same idea at once. Engineers got the green light to expense a Mac Mini, install OpenClaw, and run their own agents. They had the technical foundation to do it. A few were interested. Most were not...and not because they doubted the technology. They wanted to do engineering work, not become the person physically managing a computer, nursing it through upgrades, and debugging a new piece of infrastructure on top of everything else they already owned.
For two nontechnical leaders, I knew that setup was not something I could reasonably ask of them, so I did it for them: bought two Mac Minis, set each up as its own environment on my desk, had each person log into their own Google, Linear, and other accounts, and configured Tailscale so I could reach the machines remotely. It was workable but kludgy. The machines had their own edge cases, their own logins, their own opportunities to go offline. More importantly, I had confused access with usefulness. They did not want a new system to babysit and tune. They wanted something that worked.
I am a tinkerer. I am comfortable redirecting an agent when it goes sideways and gradually dialing in a system over months. That is not a reasonable expectation for busy leaders, especially nontechnical ones. I had handed them an early experiment and called it empowerment.
Two lessons came out of this failure. First: if your AI strategy requires people to become part-time IT or part-time prompt engineers, you do not have an AI strategy. You have a hobby. Second: the immediate fit was technical work, tasks with clear tools, artifacts, and feedback loops. We eventually found much better ways to unlock nontechnical work, but a small computer and a request to become an agent operator was not one of them.
The agent that could fix the agents
The hardware was only part of the problem. OpenClaw was a fast-moving open-source project releasing updates daily, and applying one had a very good chance of taking the entire gateway offline. The failure mode was awful: an agent that had been answering in Slack would simply stop. No useful error, no health check, no visibility into why. When an update broke the agents on my Mac Studio, I had no independent way into the system to fix it.
So I ran a proof of concept. I stood up a small Linux VPS in the cloud, put an OpenClaw agent on it, and gave it permission to SSH into the Mac Studio through Tailscale. This was an early, bounded recovery path for my personal machine, not the pattern we used for the later fleet. When the local agents broke, I could still talk to the cloud agent in Slack, and it could do more than suggest fixes: it could inspect logs, trace the failure, try the next diagnostic step, and keep going without me copying and pasting commands back and forth. Depending on what it found, it could install an update, restart the software, clear disk space, or fix the configuration.
That recovery path was the real unlock. The cloud agent was doing the same competent work as its local counterparts, but it was not dependent on my Mac being healthy. For the first time, I could see that an agent did not have to be an extension of my computer to be powerful. It could be an independent system.
The question changed from "how do I give everyone a Mac?" to "do these agents need to run locally at all?" For nearly every company use case, the answer was no. And the experiment taught me something else that would compound later: agents can build and operate systems for other agents.
The cloud was the answer
When it was time to stand up more agents, I did not buy more Mac Minis. The cloud agent was working, easier to maintain, and available when the local machines were not. But the deeper reason was that I had started to see the agents differently.
My earliest agents were deeply personal. They ran on my machine and felt like extensions of me. Once agents appeared in Slack, took on bounded work, and kept it moving on their own, they began to look much more like coworkers. And I would never give a coworker raw access to my iMessage history, personal reminders, or the rest of my Mac life. Why would I give it to an agent? A company agent needs a place to run, a way to communicate where the team already works, access appropriate to its job, and an identity that makes its work legible to everyone else. It does not need a private computer under someone's desk.
The cloud also gave us something local machines never did: observability. OpenClaw could emit standard telemetry, which let us instrument the fleet centrally and see how agents were behaving, where they were failing, and whether they were healthy. That beats waiting for someone in Slack to notice an agent has stopped answering.
So I gave one of the agents a repository and asked it to build the infrastructure-as-code foundation for deploying agents safely. It generated the first version in OpenTofu. That was the first time I really understood the compounding leverage: an agent could help build the repeatable system used to provision the next agent. Provisioning a fleet manually is an enormous IT project. Once an agent can write the infrastructure as code and troubleshoot the next agent, the human is no longer assembling every piece by hand. The work still needs careful design and boundaries (it is not magic) but it is a massive leverage multiplier.
We moved the agents into a separate cloud environment with no network path into Texture's production systems. They live in Slack, where the company already lives. They can pull the codebase, work on a task, open a pull request, check monitoring data, and report back in the same channels people already use.
No new app. No private computer for every employee. No pretending that an agent is secretly its owner.
Which surfaced the harder question: if these agents were going to act like coworkers, who were they in the systems where the company actually works?
The strange case of the invisible coworkers
With one agent, ambiguous ownership was survivable. With several agents working in parallel, it became an operating problem.
Imagine hiring four engineers and making them all share one email address, one GitHub account, one Slack account, and one badge. If something changes, you have no idea who changed it. If an alert comes in, there is no clear person to route it to. If a task needs follow-up, you cannot tell whether the owner has even seen it.
That is not a team. That is a trench coat full of people.
We tried to paper over the problem before we solved it. GitHub Apps. Agent names in branch prefixes. Issue tags in Linear to mark which agent was supposedly working on what. All of it helped a little. None of it fixed the underlying issue.
One version was especially ridiculous. We were assigning work in Linear to me, then adding an agent tag to explain it was not actually mine. From a project-management perspective, it looked like I had a mountain of tickets and was not getting through any of them. In reality, several agents were working in parallel, but the system had no way to represent that. You cannot coordinate a team when nobody has a legible identity or actual ownership.
The answer was embarrassingly literal: treat every agent like a new hire.
Give every agent a badge
When a new engineer joins Texture, we do not hand them somebody else's laptop and say, "Good luck, try not to break anything." We create an identity. We give them an email address, a Slack account, a GitHub account, access to Linear, access to the tools their role requires. We decide what they should be able to see and do. We make their work attributable to them.
That is now the model for agents at Texture, too.
Each agent gets its own identity. Its own email. Its own Slack presence. Its own GitHub account. Its own Linear account. Its own 1Password vault, managed through a dedicated 1Password service account, holding only the secrets explicitly provisioned for it. Credentials are scoped to the work the agent actually performs. If an engineering agent needs read access to logs, it gets read access to logs. It does not inherit a founder's entire digital life because that was convenient on day one.
None of this is a novel security concept. It is basic identity and access management. The mistake is thinking the basic rules stop applying because the new teammate happens to be software.
The payoff is bigger than security. Identity gives the organization a way to move work between agents without turning a human into the switchboard. You can assign an issue to a specific agent in Linear, let it pick up the work autonomously, see who opened the pull request, and know who owns the next step when it needs review. Other agents can route work to it because the systems they use can represent it as a real actor.
The same identity creates accountability. You can see where model spend went, revoke access cleanly when a role changes, and trace a secrets-manager change at 2am to the actual actor. The mystery that opened this post becomes impossible: the record says exactly who changed it, human or agent.
The boring foundation matters
We did not get here in one elegant leap. The implementation evolved in stages: first a few expedient shortcuts, then shared infrastructure, and finally per-agent identity and scoped access. Each step made the fleet more capable. Only the last one made it legible enough to operate as a team.
This is the point where people sometimes get bored because it sounds like administration. It is administration. It is also the thing that makes the exciting part possible. A fleet cannot take on real work if nobody can answer basic questions about it: Who did this? Who owns it now? What can it access? What happens when it leaves? What is the blast radius if it gets something wrong?
The practical version looks a lot like an onboarding checklist:
- A distinct, attributable identity. Email, Slack, GitHub, and Linear accounts, along with the credentials they use, belong to the agent and are scoped to its role, not its human sponsor.
- Least-privilege access. Start with exactly what the role needs. Read-only is the default for sensitive systems. No agent has a standing path to customer data or sensitive grid data, and the fleet runs in its own cloud environment with no network route into the systems that run our platform.
- A clear job. General-purpose assistants are useful. Specialists with a defined area of responsibility are much easier to trust, evaluate, and improve.
- A human review boundary. Agents can investigate, write code, and open pull requests. A human reviews before anything reaches production.
The first four are what let an agent work independently. The fifth is what lets the company sleep at night.
There are still very practical annoyances. A lot of modern software assumes every account belongs to a person with a phone. Setting up service accounts sometimes means fighting human-verification flows designed for a world with no software coworkers. We have solved that problem in ways that felt far more like managing burner phones than running an engineering organization: numbers to receive verification texts, workarounds for "prove you are human" gates, identity ceremonies designed for beings with thumbs.
It is funny until you realize it is a product gap. Every tool companies use to manage human employees, HRIS, IdP, expense systems, and seat-based licensing, assumes the workforce is made of people. None of it is designed for a workforce that includes nonhuman members with real accounts, real access, and real spend.
It will be. Whoever builds it first is going to do very well.
When the org chart starts to appear
The most interesting change came after the identities were in place: the agents started routing work to each other.
One of the roles I stood up was a Chief-of-Staff agent. More on that role in a future post, but it made the new operating model tangible. A bug report comes into Slack. The Chief-of-Staff agent acknowledges it, checks for duplicates, creates the issue, and routes it to the engineer-agent best suited to investigate. That agent works the problem and opens a pull request. The Chief-of-Staff agent follows up, surfaces blockers, and makes sure the right human sees the review request. No person had to act as the switchboard. That only works because each participant has a recognizable role, a place to receive work, and a record of what it did next. Identity is the coordination layer, not just the access-control layer.
None of this means the agents are running the company. It means the company finally has a system that can represent work moving between accountable actors, whether those actors are human or software. Identity is also what made the fleet able to learn: with a legible record of who did what, each correction and each round of human feedback can be attributed, reviewed, and turned into durable lessons for the specific agent that needs them. How that learning loop works, including playbooks, memory, and what OpenClaw calls dreaming, is a story for later in this series.
What I'd tell anyone starting this
None of this was about making people invisible or replacing them with a wall of bots. It was about removing the mechanical work that pulls good people away from the decisions only good people can make. The same discipline turned out to be better for everyone. Engineers get fewer drive-by interruptions. Nontechnical teammates have a clearer path to getting small changes made. Leaders see real ownership instead of decoding tags and branch names. And the agents can take on meaningful work without borrowing somebody else's authority.
Give an agent a job, a badge, the smallest useful set of keys, and a clear line it cannot cross. Then people and agents can work together with real ownership, clear accountability, and a system you can actually scale.
Identity tells you who an agent is and what it can access. It does not guarantee it will make good decisions. That requires a different kind of system: hard guardrails, human review, and a very deliberate definition of what an agent should never be allowed to do on its own.
That's Part 3.
