I built this for myself first | Texture

Back to Blog<br>I built this for myself first<br>The first chapter in how Texture moved from one founder’s personal AI experiment to an agent fleet the whole company could use.

Victor Quinn , Co-founder and CTOJuly 23, 2026•9 minute read

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...