Building an Agentic Software Team. First Attempt - March 2026

There exists a dream of handing off an idea to an agentic AI team, grabbing a coffee, and coming back to a working product. This dream is not new. And, many are still striving to get there. Yet, despite what much of the hype in the news says, there's still plenty of work to be done.

This post will cover my own initial attempt. An attempt informed by recent works on the matter.

Much of this builds of the idea of using agent skills and sub-agents. Which are covered here:

Understanding Skills and Sub-Agents in Claude Code

A beginners conceptual guide to Claude Code skills and sub-agents. These principles apply to other CLI Agents as well.

Ground Test JournalRyan R

This post covers:

• My initial approach
• Discussion on results
• Some improvements:
  • agent communication plans
  • Stricter documentation folder structure

Hypothesis

Building out a small agent team with the same principles I use to build one at a company. Mainly these capabilities:

• Project scoping based on user needs
• Project management
• Developers with skillsets related to the architecture desired
• Standards to work by

Looking at these basic needs, one can already image the sub-agents we'll need: a product manager, project manager, and a few developers depending on the needs.

Another requirement: specifications before build.

This means that code is only written after it has been specified. For example, a user button would not exist without it being explicitly placed in the spec. This serves a dual purpose:

• specifications serve as the source vs the code being source (spec-driven development principle)
• Serves as a working memory for agents.

The approach

Here, I do a draft of the scope, "hire" the team by specifying agents and their skills. I then provide

The project

The project would be something I've built before. Something that I understood the ins-and-outs of and the traps.

This would be a UI wrapper around a machine learning library for anomaly detection (namely Anomalib).

What's nice about this project, the UI and machine learning aspects were well defined by documentation. No real custom work. Mainly, integrating two frameworks.

From this, I could write out a simple markdown file that described the architecture and the needed capabilities.

The team

Since I already understood the need for a product and project manager, I just needed to define the roles for the developers. Here, I would need two: A UI expert for the framework chosen and an expert in Anomalib.

This is the final team:

• Product Manager: the role is to define the scope more concretely, including requirements.
• Project Manager: creates plans and tasks based on the requirements.
• UI Develoer (Gradio framework):
• Anomalib Developer

Each of these is defined in a .md file in an agent file within the project, namely project-directory/.claude/agents/agent-name.md. Simply replacing .claude with .agents allows one to use OpenCode or Gemini.

Documentation methods

I spent time defining what a documentation should look like, how detailed it should be, and how it is updated. This was done for specifications (requirements, user needs, scheduling (project level and task level), and status update files. The last needs to be explained.

For memory to persist and to provide a means of inter-agent communication, I made it a requirement of each agent to write a status update. This status update is one file per agent and only included current work. It's equivalent to a real person providing status updates for a meeting. Almost like making a slide for a presentation. It's meant to be brief and cover what was done and if there were any blockers.

For structure of documents, I provided a folder structure I wanted the agents to place documentation. This would be the source of truth for all agents. The directory structure looked like this:

• docs/
  • project_overview/
  • planning/
  • architecture/
  • status/

The skills

I viewed this like filling out a hiring plan for the agent being hired. This is something I do in real life: provide HR with a breakdown of skills with context. My HR manager was Claude Code. Claude Code was given a skill called skill-creator, a popular one on skills.sh that is managed by Anthropic.

I gave Claude Code a description of the skill I wanted, told it to invoke the skill-creator skill and let it go. It would then store that skill within the project-directory/skills folder.

After a number of sessions with Claude Code focused on the skills I wanted, I ended up with this set of skills that looked like this:

• requirements_breakdown.md
• user_needs.md
• phase_scheduling.md
• status_updating.md
• ...
• python_standards.md
• gradio_ui.md
• anomalib.md

The all-inclusive list is a little long for a blog post. But, it gives you the idea. Skills are broken down into task-like skills or knowledge-based (like UI library knowledge and coding standards).

The agents

In each of the agents, I specified the exact skills they needed. The AGENT.md file allows for you to specify not only a system prompt but also specific skills these agents employ.

This step was minimal. Most of the work was in building the skills. Here was just listing the skills each specific agent needed.

This is related to the "hiring" analogy mentioned earlier. Agents were hired based on their set of skills, which already had their own detailed specifications. Here are the agents that were hired:

• Product Manager
• Project Manager
• Anomalib Developer
• Gradio Developer

The Results

At the start of the process, almost all of the time was spent with the Product Manager. I gave the Product Manager an initial scope document based on what I wanted. Then, handed that off to the project manager to create a phase-based project plan. Once, happy with that. I had the project manager scope out the first phase in detail (i.e. task breakdown).

Most time was spent here--about 2 days. After, I never actually invoked the developer agents myself. Instead, I had Claude Code overlook the current tasks and call the 2 sub agents as necessary.

The initial result showed a working GUI, but there were errors in the Anomalib implementation. Much of which were fairly basic. Much of the code written was good. However, there were some gotchas in how Anomalib specifically handles its pipeline, which can be different than what is expected of a pure machine-learning workflow.

After a few extra sessions, bugs were being figured out. However, one big issue popped up. How do we integrate the UI with the backend? Which agent handles that?

This resulted in an interesting scenario: the project manager decided to create an API contract. So, in effect, it created a mediator document that both developer agents could look at. It worked, but it definitely took the Project Manager out of its intended purpose.

It also highlighted that the communication between agents was lacking. The point of communication was not with each other, but through the project manager. And, if you've ever led a real team, this is not the way. The project manager shouldn't be defining code structure nor serving as a mediator between individual developers (unless there is a problem).

Additionally, the system seemed to be obsessed with creating specs. And, eventually, ignored the documentation folder structure. At one point, I had about 30 documents. I got around this by having the project manager consolidate the documentation, which took a couple of iterations to really get there. I even had to threaten the agents that I would delete the files and that it was their last chance to consolidate or the info would be lost...

This brings me to some improvements.

Improvements for next time

Primary improvements are these.

Strict documents

I would pre-define the structure and documents. There would be no room for the agents to make new files inside that structure. They would have to stick to the documents already existing.

More so, the project manager would have the document structure laid out in its system prompt. It would serve as the structure enforcer.

Ideally, I would also limit what documents each agent could write to. However, I will need to research how to do that. It would be analogous to a project folder in real team projects that only allow certain people to edit and approve.

Communication plan

There would be a communication plan for the agents to follow. This is very similar to real project management. The agents would agree ahead of time on how to share information. For example, there would be one status file that all would update. In there they could review other agent's progress and could make decisions based on that.

This could involve creating a RACI skill and document. Where agents are given specific designations on parts of the project. RACI stands for Responsible, Accountable, Consulded, Informed. These would help clarify to agents responsibilities in specific parts of the project.

For example, a developer would be Consulted for API integration.

Possible approval process

In projects involving people, there needs to be an approval process. This could be delegated much to the product manager. However, I may make certain cases approved by me (the user).

An integration developer

This developer would explicitly be responsible for handling the API between the front-end and the backend. It would consult the other agents (via a communication document) on best practices for their frameworks. It would then be the expert at deploying that API.