Watch It Work | Texture

Back to Blog<br>Watch It Work<br>Real Slack conversations show Texture's AI agent fleet triaging bugs, shipping work, investigating alerts, and co-piloting a production database migration.

Victor Quinn , Co-founder and CTOAugust 13, 2026•14 minute read

Part 4 of a 5-part series on running an AI agent fleet inside a real company

The first three parts of this series explained the architecture, identity, access, and human gates behind our agent fleet. This one is the receipts.

What follows is a set of real exchanges from inside Texture: our team interacting with agents in the same Slack channels where we already work. These are not mockups, reenactments, or examples curated for publication. They are actual internal conversations, written in the moment by our team members and agents while doing the work and reproduced without rewriting. Had we known they would appear publicly, we might have phrased some things differently. Where necessary, we have only cropped the conversations or removed sensitive or irrelevant information. The messiness is part of the point. This is what the work actually looks like inside Texture.

Together, they show the whole model in motion: a human asks for an outcome or an operational event arrives, the fleet gathers context and does the work, and a human retains the consequential decision.

A Slack bug report becomes one diagnosis and three reviewable pull requests.

It starts with a human. Stefan, a member of our team, reported a bug in the dashboard to our #bugs Slack channel. Morgan then picked it up, checked for duplicates, created the Linear issue, and routed it to Lyra. Lyra found that the reported symptom shared a root cause with two other problems, fixed all three, and opened the pull requests.

However, neither Morgan nor Lyra are real people.

Morgan is my Chief of Staff agent. Lyra is one of our engineer-agents. The person reporting the bug did not have to copy it into a ticket, translate it into engineering language, decide which agent should handle it, or keep the handoff alive across multiple systems. They reported the problem in Slack. The fleet did the rest, right up to the point where a human needed to review the code and decide whether to ship it.

This is the emergent org chart I described in Part 2: Give Every Agent a Badge, now doing ordinary work. A report is filed through the same channel our team already uses. One agent handles intake and coordination. Another handles the technical investigation. The work comes back to humans as reviewable pull requests.

That is what the fleet looks like most of the time. It is not a row of chat windows waiting for me to invent prompts. It is a set of operational loops woven into the places where the company already works.

Remove the translation layer

Our CPO gives Web-Dave the Figma designs and the outcome he wants.Web-Dave returns the pull request, live preview, visual comparison, and validation results.Our CPO and Web-Dave joke about earning a burrito as the work lands, escalating from burrito to guacamole to queso to horchata as more ships.

And yes — if you noticed Web-Dave sign off with "Burrito proximity: high" above, here is the context. Somewhere along the way, the website channel developed a running joke: good work earns a burrito. As more shipped in a session, the stakes escalated from burrito to guacamole to queso to horchata. It is a small, silly, entirely emergent thing, and it is exactly the kind of texture you get when agents work in the same rooms as the rest of the team rather than behind an API.

During our website redesign, we put an agent named Web-Dave in the website team's Slack channel.

Marketing and product worked with Web-Dave directly on the redesign. Sometimes that meant copy or layout. More often it meant substantial product work: rebuilding major components, changing the menu system, restructuring pages, and creating the Contentful-backed blog you are reading now. They could describe what they wanted in the channel, and Web-Dave would make the code change and return a preview link in the same thread. The person who requested the change could click through a real version of the site, decide whether it matched what they meant, and ask for another pass if it did not. Once a human was satisfied, a human approved and merged it.

The interesting part is not that an agent can change website copy. Any modern coding model can do that. It is that non-engineers could drive sweeping, structural changes to a production website without turning every idea into a request for an engineer.

It is worth being concrete about the scale of that. Our website redesign produced a custom Next.js site, heavy on real application code, backed by Contentful, the very site you are reading this on. For a custom, production marketing site, that is genuinely remarkable.

The teammate requesting the work no longer needs to translate it through an engineer. They do not have to write a ticket in engineering...