Building an AI agent that chats is easy. Building an AI agent that can autonomously spin up development environments, navigate file systems, read code, write dependencies, and run tests is a fundamentally different engineering problem.
This is the story of CoWorker, an advanced AI microservice I recently built for V-Collab.
V-Collab is our cloud-agnostic development environment manager. Think of it as a robust platform that spins up isolated workspaces where developers can jump right into coding. Every workspace runs an internal agent that exposes necessary apps like a web-based VS Code, terminal access, and VNC GUIs.
The goal with CoWorker was simple in concept but difficult in execution: Give the user an AI assistant that can seamlessly bridge the gap between the platform (V-Collab) and the internal workspace context.
The Architecture: Go, Azure AI Foundry, and GPT-5.4 Pro
We decided to build the CoWorker microservice entirely in Go. The concurrency model and performance characteristics of Go make it ideal for handling heavily I/O-bound agentic workflows, especially when juggling multiple user requests across different workspaces.
For the brain, we utilized GPT-5.4 Pro hosted on Azure AI Foundry, which provided the immense reasoning capabilities needed for actual coding tasks.
Iteration 1: The Monolithic ReAct Agent
For the very first iteration of CoWorker, we implemented a single-agent architecture using the classic ReAct (Reasoning and Acting) pattern.
The ReAct Loop
In the ReAct pattern, the LLM is trapped in a continuous `while` loop. It observes an input, reasons about what to do next, executes a tool (acts), observes the output of that tool, and repeats until the final goal is met.
Because CoWorker needed to interact with the actual code inside the isolated V-Collab workspaces, we utilized the Model Context Protocol (MCP). We wrote an MCP server in Go that lived alongside the workspace agent.
This MCP server exposed critical capabilities back to our central CoWorker agent:
read_file/write_file/edit_filerun_command(for installing dependencies or running tests)monitor_processandcheck_app_health(checking if a port was successfully bound)
Where the Monolith Broke Down
The single-agent ReAct loop was a great proof of concept. You could tell it, "Set up a Node.js project and write a basic Express server," and it would dutifully use the MCP tools to run `npm init`, create `index.js`, write the code, and start the server.
However, as we pushed the complexity, the limitations of a single-agent monolith became glaringly obvious:
- Context Window Bloat: A single agent had to hold the system prompt for *everything*. It needed instructions on how to use V-Collab APIs, how to write code, how to use the MCP tools, and how to debug. The context window filled up rapidly with tool execution logs.
- Loss of Focus: When an agent is responsible for provisioning platform infrastructure *and* fixing a syntax error in a JavaScript file, its reasoning capabilities degrade. It tries to do too much at once.
- Execution Time: The ReAct loop is strictly sequential. It thinks, acts, thinks, acts. Waiting for the LLM to complete full cycles just to figure out it needed to list files before reading them was painfully slow.
We realized that to make CoWorker truly robust, we needed to break the monolith. We needed specialized agents that could talk to each other. We needed to migrate away from a raw ReAct loop to a structured framework.