Part 1 of a 5-part series on running an AI agent fleet inside a real company
A Sentry alert fires.
Our Chief-of-Staff agent picks it up, figures out which of our engineer-agents is the right fit for it, opens a Linear ticket, and assigns it. That agent gets to work, investigates, writes the fix, opens a pull request, and then pings the right person: this is ready for your review. A human looks it over, and if it's good, merges it. From alert to a reviewed, merged fix, the only human effort was the part that should stay human: the decision to actually ship it. Nobody got pulled out of what they were doing to get there.
That's where this is going. It is emphatically not where it started.
Where it started was a lot dumber, and a lot more manual: me, alone, with my own credentials, tinkering.
A little personal context
For most of the last decade, writing production code from scratch wasn't my day job. Most recently, as VP of Engineering at a Series B startup, I ran engineering, IT, technical project management, data engineering, and data science, an organization of 65. Before that, as a Senior Director at a much larger company, I led Directors who led Senior Managers who led Engineering Managers, overseeing a team of 100. That was strategic leadership, not day-to-day coding. But I never stopped writing code. I kept my hands on the architecture, kept maintaining open-source projects, kept tinkering constantly on the side. Code was always there; it just wasn't the bulk of what I did in a given week.
Then we started Texture, and for a while I was the only person on the technical side, responsible for shipping all of it myself, from zero, at speed. AI turned out to be a real lever there: not a crutch for someone who couldn't code, but a force multiplier for someone who could and suddenly had to do a lot of it, fast. That's the seed everything else in this story grows out of.
Before I started building agents
Like most people, I started with the hosted tools. I used ChatGPT and Claude constantly, the way a lot of technical people did: to work through ideas, ask questions, debug, and get unstuck faster. They became part of how I worked long before I was trying to build anything autonomous.
Then Claude Code arrived. I used it heavily throughout 2025, and it changed the shape of the work again. This was no longer just a conversation in an app. I could put an AI directly alongside the codebase and have it help make real changes. It was a meaningful force multiplier, but it was still a tool I had to sit in front of and drive.
By the time I started looking at agent harnesses, I had already seen enough to know the underlying capability was real. The question was whether I could turn it from something I used in a session into something that could take on bounded work and keep moving when I was not staring at the screen.
The naive first move
I spun up a single agent on OpenClaw.
OpenClaw is the open-source framework this whole story runs on, the layer that takes a large language model and turns it into a persistent agent: something that lives in the tools you already use, holds context over time, and can actually take actions on its own instead of just answering questions in a chat window. Everything across all five of these posts is built on it, so it's worth naming up front.
I gave that first agent my own GitHub personal access token, my own email, my own everything, and started tinkering. It could commit code and open pull requests exactly the way I would, because as far as GitHub was concerned, it was me. There was no difference in the system between "Victor wrote this" and "Victor's agent wrote this."
That was the whole point. It was also, eventually, the whole problem, but that's getting ahead of the story.
From the start, the infrastructure behind all of this has run separately from Texture's production systems, on its own cloud environment with no network path into the systems that actually run our platform. The access model, even at its most permissive, is least-privilege and read-only. No agent has ever had a path to customer data or sensitive grid data. Everything in this series happened inside that boundary. I'll come back to exactly what that boundary looks like later in this series, but I want it stated plainly up front, because I know how "we gave AI agents a lot of autonomy" sounds if you stop reading there.
They didn't know what I meant yet
Here's the part the demos never show you: at the beginning, the agents weren't terrible at the work itself. They could often write perfectly reasonable code. The problem was that they had none of the context for how I wanted work to happen. They asked a lot of questions, requested permission for every next step, and hesitated to investigate or make a call. In a chat window, that can feel prudent. In the kind of bounded environment I had set up, where the meaningful handoff was a pull request for a human to review, it was mostly friction. I didn't need a very fast assistant waiting to be told what to do next. I needed a teammate that could take a problem, investigate it thoroughly, anticipate the questions I'd ask, and bring me a considered answer.
That distinction mattered. I wasn't trying to give an agent blanket permission to do whatever it wanted. I was trying to teach it the operating model: be proactive inside the work you're assigned; use judgment; explore the relevant paths; pressure-test the answer; and surface the decision that actually needs a human. I make heavy use of red-team analysis for exactly that reason. I don't want the first plausible answer. I want someone, human or agent, to look for the thing we missed before it becomes the problem.
So I kept at it. Every time an agent got something wrong, I corrected it: more context, better guidance, clearer expectations about what "good" looked like. And every correction made it a little bit better. Then a little better than that.
It took months of steady feedback and course-correction, but the curve was real. The agents went from capable tools that still required too much direction to genuinely capable teammates I could trust with real work. After enough pressure, enough correction, and enough time, they became nothing short of amazing.
That investment, not the initial setup, is what actually produced the thing this series is about. Anyone who tries this for a weekend, gets mediocre output, and concludes it doesn't work is quitting at exactly the point where the real work starts.
One agent wasn't enough
By the time they were good, they'd made me dramatically more prolific, and almost nobody had any idea it was happening.
That's not a boast, it's the actual problem. Every commit, every PR, was tagged with my name. There was a second, invisible entity doing real work inside the company, and the system had no way to represent that. It looked, from the outside, like I'd simply gotten a lot faster.
One agent turned out to not be nearly enough. Usage was insatiable, I wanted a second, a third, a fourth, each one specializing in a different area of focus. But they were all still sharing that same personal access token. Four entities, one identity. That's the seed of a problem I'll spend most of Part 2 unpacking, but it's worth planting here: the moment you have more than one of these things, "borrow your own credentials" stops scaling, even if you don't notice it yet.
Super Bowl Squares
The moment I understood how high the ceiling really was wasn't a benchmark or a demo. It was a Sunday in February, during a company retreat in Denver.
We'd flown the whole team in from around the country for an onsite. Then we realized we'd accidentally scheduled it over Super Bowl weekend. A few people on the team who were more fluent in sports than the rest of us suggested a Squares pool, the classic grid game where you bid on a square, and if the final score matches your coordinates, you win. It was a fun way to make the game interesting for everyone, so I decided to build it live, on the spot, entirely by talking to my agents.
In a matter of hours, before the game even started, it had real authentication and a full database backend. We kept building during the game, and by the final whistle it also had live WebSocket updates wired to a sports-data feed, so everyone could watch their squares light up as the score changed. Vibe-coded at a company retreat, in an afternoon, and it actually worked.
That was the moment the whole thing stopped feeling like an experiment. This wasn't a toy or a party trick. It was a genuinely powerful way to build.
Why Slack, and not the thing the docs tell you to use
Small decision, bigger consequences than it should have had: most agent-framework documentation nudges you toward Telegram as the default chat interface. Reasonable enough as a starting point, but it assumes your team is already there. Ours wasn't. I could have told every engineer at Texture to download Telegram just to talk to an AI agent, but that's friction, a new app, a new login, a new habit, for a benefit nobody's convinced of yet.
Slack, on the other hand, is where the company already lives. We're fully remote, so for most of us, Slack basically is the office. If an agent could just show up there, like any other person you work with, the adoption curve looks completely different. You don't have to convince anyone to change how they work. You just have to convince them to type an @-mention to someone new.
The decision to meet people exactly where they already are turned out to be one of the most consequential things I got right early. It is a theme that shows up again and again in this series: the technology mattered less than how much friction stood between someone and actually using it.
Out into the company Slack
By this point I had a handful of agents, all specialized, all genuinely good after months of that back-and-forth, and all still running on the Mac Studio sitting on my desk in the office. But they were still entirely mine. I interacted with each of them one-on-one in DMs; nobody else at Texture had talked to them or even had a reason to.
So instead of keeping them as my private set of helpers, I did the simplest possible thing: I added them to channels the whole company was already in. #eng. #bugs. No DM required, no new tool to learn, no habit to build.
And it worked exactly the way you'd want it to. Just like a human co-worker, someone would post in the bugs channel, "hey, this is broken", and someone would pick it up. Except here, the someone who picked it up was an agent, which would quietly go do the investigation, find the problem, and fix it, without a human pulled in to babysit it. To the person who reported the bug, it barely registered that a person hadn't been the one to handle it. The work just got done.
That's when it stopped being my personal productivity hack and became something the whole company could see and feel.
The realization
Once people saw what my agents could do, the obvious question landed almost immediately, and I was already asking it myself: if this is this useful when it's just my handful of personal agents, why doesn't everyone have this?
That's the moment the whole thing turned from a personal experiment into a company project. I decided to start standing up agents for the rest of the team, and that decision kicked off an entirely new set of problems I hadn't even imagined yet: where do these things actually run, whose identity do they use, and how on earth do you keep track of which one did what.
That's Part 2.
This is Part 1 of a 5-part series on how we built and rebuilt the way AI agents operate inside Texture, from tinkering with personal credentials to giving every agent its own identity, access, and accountability. Part 2 picks up where the "just me" era ends: the messy process of deploying agents for a whole team, and the surprisingly literal fix that came out of it, treating every agent like a new hire.
