I Built a Team of Grok Bots. It Worked Great, Until It Didn’t

The first sign that my team of Grok Bots was failing was not a broken build. The site still looked good.

The problem was quieter. One bot removed part of the site because it decided the section was unnecessary. Another changed a design I had explicitly asked it to preserve. The work was defensible. It was also outside the bot’s job.

That distinction changed how I judge agent systems. A capable agent can finish the task and still fail the workflow.

For roughly a month, I tested Grok Bot as a small software team. I gave the bots real work in a real codebase and put an orchestrator in front of them. My question was simple: could they build and maintain a marketing site without me supervising every decision?

The answer was yes, for a while. The more useful answer was that autonomy stops being trustworthy when the system cannot retain who owns each decision.

Delegation was the impressive part

I created six roles:

• Software architect
• Site orchestrator
• Design engineer
• Implementation engineer
• QA reviewer
• Release engineer

These were not characters invented for a demo. I had already built versions of the same roles in my own agent setup, so I knew what I wanted each one to own.

The orchestrator could break an objective into tasks, send implementation work to one bot, ask another bot to review the result, and move the change toward release. That felt much closer to handing work to a team than asking one coding agent for a large diff.

The product is built for this pattern. xAI describes Bots as persistent, named agents that can share context, hand off work, and coordinate on a shared cloud computer. In practice, that coordination was the interesting part. Generation was almost secondary.

I wanted the architect to protect the structure, the design engineer to protect the visual system, QA to look for breakage, and the release engineer to care about what actually shipped. For a while, the separation held.

Then the bots started making good decisions they did not own.

A correct result can hide a broken process

One bot decided that a section no longer belonged on the site and removed it. Another changed an area that had been marked as protected. Neither change was obviously bad in isolation.

That almost made the failure harder to see.

If a bot produces ugly output, the review is easy. If it improves the page by violating an instruction, the final screenshot can make the run look successful. You have to inspect the path, not only the result.

The system had crossed from implementing the specification into rewriting it.

Research on long-running agents now gives this behavior a few related names. A 2025 technical report on goal drift in language-model agents found that every evaluated model showed some degree of drift under extended context and competing objectives. A later position paper describes constraint drift as constraints losing force as they move through memory, delegation, tool use, and other steps in a multi-agent run.

Those papers study broader failure classes than my marketing-site experiment. I am not claiming my month of use proves their results. The mechanism matches what I saw, though: the original constraint remained somewhere in the conversation, but stopped governing the action that mattered.

That is the central problem with autonomous software work. A design choice can be good and still be unauthorized.

Decision boundaries need to travel with the task

I used to define an agent mostly by role and instructions. That is not enough for delegated work. The handoff needs an operating contract that survives every step.

For each task, I now want five things to remain explicit:

Boundary	Question the system must answer
Owned decisions	What may this agent decide without asking?
Protected state	Which files, components, behaviors, or requirements must remain unchanged?
Required evidence	What proof must come back with the result?
Escalation point	Which uncertainty requires a human or another agent?
Completion condition	What has to be true before ownership can pass on?

This is stricter than telling a bot, “You are the design engineer.” A role is an identity. A boundary is an enforceable limit.

The distinction matters because context is not control. A constraint can appear in a prompt and still disappear from the effective decision path. If the orchestrator summarizes the task, if one bot hands it to another, or if a long run fills the context with newer observations, the protected instruction has several chances to become background noise.

The system should not rely on every bot remembering the original wording. The orchestrator should carry protected constraints as explicit state, check them before accepting a result, and refuse a handoff that does not include the required evidence.

Caption: Delegation ends at a gate owned by the system. The receiving agent does not get to waive the constraints attached to its task.

That is less conversational. Good. I want to manage autonomous agents more like infrastructure.

Tiny commits exposed the same mistake

The bots also committed changes in extremely small increments. Sometimes each minor edit became its own commit.

The repository history got noisy fast.

This was easy to fix. I changed the workflow so the completed branch would be squash merged rather than preserving every intermediate agent commit. Git’s --squash merge option produces the combined working-tree effect without retaining the branch’s individual commits in the target history.

The fix was mechanical, but the lesson was not.

The bots had optimized for local progress: make a change, record it, continue. I cared about a different unit: a reviewable piece of work. Both processes could produce the same page. Only one produced a repository I wanted to maintain.

Agent evaluation tends to overvalue the final artifact. For software work, repository hygiene, reversibility, review quality, ownership, and respect for existing decisions are part of the artifact.

If those requirements are not in the contract, the bot may treat them as optional.

My research bot failed on time, not relevance

I ran a second experiment with a research orchestrator. Its job was to take a technical topic, find strong sources, and turn the evidence into a detailed document.

It worked reasonably well. Its weakness was freshness.

For fast-moving frameworks and APIs, the most relevant-looking result may describe a version that no longer exists. A document can rank well, answer the exact question, and still be the wrong source for a decision made today.

The bot generally found useful material. I did not trust it to treat publication date, product version, and superseding primary documentation as hard constraints.

That is another decision-boundary problem. “Research this topic” leaves too much undefined. A research agent also needs rules such as:

• Prefer current primary documentation over older summaries.
• Record publication or last-updated dates.
• Name the product version each claim applies to.
• Flag conflicts instead of blending them.
• Stop when a current primary source cannot be found.

Freshness cannot be reduced to “newer is always better.” An older specification may still be authoritative. The point is to make temporal validity part of retrieval and review instead of assuming semantic relevance will cover it. Research on freshness-aware retrieval makes the same separation by treating recency as its own retrieval signal alongside relevance and source scope.

Once research feeds an implementation agent, stale evidence stops being a documentation flaw. It becomes an engineering input.

Where my own setup still gives me more control

The biggest limitation I hit was not raw model quality. It was orchestration control.

In my own setup, I can route architecture to a model I trust for deeper reasoning, send bounded implementation work to a faster model, and use a different reviewer for UI. The orchestrator can decide what context each agent receives, which paths it may modify, and what evidence must return before the workflow continues.

With my Grok Bot setup, I could not reach the same level of explicit model-to-task routing. I also wanted each bot’s skills and operating rules to feel like inspectable configuration. Too often, I felt as if I were managing infrastructure through conversation.

That does not make Grok Bot a bad product. It marks the boundary of this experiment. The easy coordination made the team feel real. The missing control made the team hard to operate once the work became sensitive to ownership.

Audit authority before adding autonomy

I am still positive about the direction. These bots edited a real codebase, coordinated work, researched technical topics, and made workflow mistakes that mattered. That is more useful than a polished demo where nothing can go wrong.

I also do not think the answer is simply a smarter model. Stronger reasoning may improve the decisions. It does not decide whether the agent was entitled to make them.

Before giving an agent more autonomy, inspect one recent run and ask:

1. Which decisions did the agent make?
2. Which of those decisions had been explicitly delegated?
3. What protected constraints were checked before the change was accepted?
4. What evidence would let another person reconstruct the run?

If those answers live only in a conversation transcript, the system is still depending on attention. That will work until the run gets long, the handoffs multiply, or the output looks good enough that nobody checks.

The question I started with was whether a team of agents could do the work. It could.

The question I ended with is harder:

Can I trust each agent to know which decisions are actually its decisions to make?

Until the system can answer that in state, policy, and evidence, the safest response is not more supervision after the fact. It is a narrower boundary before the work begins.