20 Agents, 4 Hours: Building an Enterprise Portal

16 stories. 66 story points. 108 files. 15,741 lines of code. 127 E2E tests passing. One enterprise backoffice portal. 4 hours. No detailed specs. Just plain English.

---

Two days ago, I wrote about shipping 90 hours of work in 3 hours. One person. One AI agent. One feature set. Before that, I explained why we're building GUTT—organizational memory that captures context as you work.

Today, I'm sharing something different: coordinated parallel execution.

This isn't about me directing Claude with detailed specifications. There were no detailed requirements. Just plain English descriptions of what we needed.

GUTT memory provided the context. Parallel agents did the work. MCP connected Jira, Confluence, and code.

The result: a complete enterprise backoffice portal in 4 hours.

---

The Challenge: Build the GUTT Backoffice

We needed a full internal portal for GUTT. Not a prototype. A production-ready backoffice with:

• User management and RBAC via Permit.io
• Connector management for our 8 active integrations
• Tenant administration
• Full design system compliance
• End-to-end test coverage

The traditional estimate? 3-4 weeks for a small team. Maybe 2 weeks if you pushed hard and cut corners on testing.

I had a different hypothesis: What if parallel agents could compress that to a single afternoon?

Here's the thing: I didn't write detailed specs. I didn't create technical design documents. I described what I wanted in plain English, and GUTT's organizational memory filled in the gaps.

---

The Metrics

Let me give you the numbers first. Then I'll explain how.

Not 4 hours of me coding. Not 4 hours of me writing specs. 4 hours of orchestrating parallel AI agents that could read our organizational memory, understand context from plain English, and ship independently.

---

Hour-by-Hour Breakdown

Hour 1: Planning via Memory Retrieval

Before writing a single line of code, I needed context. Not documentation—organizational memory.

I queried GUTT's knowledge graph for:

• PRD workshop context from January 16th—the strategic discussions about what this portal needed to do
• Architecture decisions—specifically Oleg's guidance to "isolate public websites from backoffice"
• Design system specs—our component library, color tokens, spacing rules
• Technical dependencies—what integrations we already had, what patterns to follow

This is the part most teams skip or do poorly. They jump to implementation without understanding context. Then they build the wrong thing, or they build it in a way that conflicts with prior decisions.

GUTT gave me the full context in minutes. Every decision, every constraint, every "we tried this and it didn't work."

I wrote a plain English plan. No Jira story templates. No acceptance criteria matrices. Just: "Build a backoffice portal with user management, connector configuration, and tenant admin. Follow our existing patterns."

GUTT memory + MCP turned that into executable work.

---

Hours 2-3: Parallel Implementation

This is where it gets interesting.

Phase 1: Story Creation

I launched 6 agents in parallel. Each agent connected to Jira and Confluence via MCP. Each agent:

1. Read a specific section of the Confluence breakdown via Atlassian MCP
2. Created corresponding Jira stories (GP-355 through GP-386)
3. Linked stories to the parent epic
4. Populated acceptance criteria by understanding the plain English context

32 stories created. 6 agents. All working simultaneously, none duplicating effort. No detailed specs—just organizational memory providing the context each agent needed.

Phase 2: Foundation & Core Features

4-6 agents per implementation phase. Each agent:

1. Searched GUTT memory for relevant context (auth patterns, component examples, API conventions)
2. Read related Confluence pages via MCP when it needed more detail
3. Implemented their assigned feature
4. Recorded learnings back to GUTT memory

That last part is critical. As agents discovered patterns, resolved conflicts, or made decisions, they wrote episodes back to the knowledge graph. The agents that ran later had access to what the earlier agents learned.

This is compounding knowledge in real-time.

No spec document could capture what was happening. The agents were figuring out implementation details by querying memory, not by reading a 50-page requirements doc.

---

Hour 4: Branding & Polish

The portal needed to show our actual connector ecosystem. I asked in plain English:

"What connectors are currently active in the GUTT platform?"

The answer came back immediately from GUTT memory: 8 active connectors

• Google Drive
• Gmail
• Google Calendar
• Microsoft Teams
• SharePoint
• Jira
• Confluence
• GitHub

No documentation lookup. No asking teammates. No searching Slack. The organizational memory knew because it had been capturing our integration work for months.

The branding agents updated the UI to showcase these exact connectors with proper logos and descriptions.

---

Hour 4 (continued): E2E Test Fixes

Here's where parallel agents really shine.

After the implementation phases, we had 52 failing E2E tests. Traditional approach: one developer works through them sequentially, maybe taking a full day.

I launched 6 parallel agents, each assigned to a subset of failing tests. Each agent:

1. Read the test failure
2. Searched memory for the component implementation
3. Fixed the test or the underlying code
4. Moved to the next failure

Result: 52 failing tests → 127 tests passing

All in under an hour. Parallel execution makes debugging embarrassingly fast.

---

What Made This Possible

1. No Specs Needed—Memory Is the Spec

Traditional development requires detailed specifications because developers can't read minds. They need requirements documented, edge cases enumerated, acceptance criteria spelled out.

GUTT memory changes this equation.

When I said "build user management," the agents didn't ask for a spec. They queried memory:

• How did we implement auth in other projects?
• What's our Permit.io integration pattern?
• What component library do we use for admin interfaces?

The answers were there. Not because I documented them—because GUTT had been capturing organizational knowledge as we worked.

Plain English + organizational memory = executable requirements.

2. MCP as the Integration Layer

Every agent could read Jira. Every agent could read Confluence. Every agent could search memory.

MCP (Model Context Protocol) made this seamless. Agents weren't copying and pasting between tools. They were directly querying:

• Confluence for feature breakdowns
• Jira for story context and acceptance criteria
• GUTT memory for implementation patterns and decisions

Three systems. One coherent context. Zero manual integration.

3. Organizational Memory as Coordination Layer

The agents didn't need me to coordinate them. GUTT's knowledge graph was the coordination layer.

When Agent 3 needed to know how Agent 1 implemented authentication, it didn't ask me. It searched memory and found the implementation details that Agent 1 had recorded.

When Agent 5 hit a conflict with Agent 2's API patterns, it searched memory, found the established convention, and aligned automatically.

This is fundamentally different from "multiple AI sessions working on the same codebase." That creates chaos—merge conflicts, duplicated effort, inconsistent patterns.

Organizational memory creates coherence.

4. Learnings Captured in Real-Time

As agents worked, they recorded episodes back to memory:

• "Created TenantCard component following existing AdminCard pattern"
• "API endpoint uses kebab-case for routes per established convention"
• "Permit.io integration requires tenant context in all authorization calls"

These aren't commit messages. They're organizational learnings that persist beyond the code itself.

The next time anyone (human or AI) works on related features, this context is available instantly.

---

Traditional vs. GUTT Approach

The compression ratio: 120+ hours → 4 hours The multiplier: 30x

But again—speed isn't the point. No specs needed is the point. Coordination without overhead is the point.

---

The Tech Stack That Emerged

For those interested in specifics:

Frontend:

• React 18 + TypeScript
• Vite (build tooling)
• TanStack Router (type-safe routing)
• shadcn/ui + Tailwind CSS (design system)
• Zustand (state management)

Backend:

• FastAPI (Python 3.11+)
• Permit.io (RBAC/ABAC authorization)

Auth:

• MSAL.js (Microsoft identity)
• Google OAuth (planned)

Testing:

• Playwright (E2E)
• 127 tests covering critical paths

Every technology choice aligned with our existing patterns because the agents knew our patterns from memory. I didn't specify "use TanStack Router"—the agents found that decision in memory and followed it.

---

What This Means for Development Teams

The End of Specification Documents

Most teams spend 20-30% of project time writing specs. Requirements documents. Technical design docs. Acceptance criteria.

Then the specs get outdated. Then developers interpret them differently. Then you need meetings to clarify what the spec meant.

What if your organizational memory was the spec?

Every decision you've made. Every pattern you've established. Every "we tried that and it didn't work." All queryable. All current. All connected.

Plain English + organizational memory = better specs than any document you've ever written.

The Era of Parallel AI Development

Most teams using AI are running one agent at a time. One developer, one Claude session, one task.

That's linear thinking applied to exponential tooling.

Parallel agents + organizational memory = multiplicative productivity

You're not limited by how fast one agent can work. You're limited by how well you can coordinate context across many agents working simultaneously.

GUTT solves the coordination problem.

MCP Makes Tools Disappear

Our agents didn't "use Jira" and "use Confluence" as separate steps. They queried what they needed through MCP, got context, and kept working.

The tools disappeared. The context remained.

That's the future of development tooling: invisible infrastructure, accessible knowledge.

Debugging at Scale

52 failing tests used to mean "block off your afternoon." Now it means "launch 6 agents and go get coffee."

This isn't about being lazy. It's about matching parallelizable work with parallel execution. Debugging is embarrassingly parallel—each failing test is independent. Sequential debugging was always a bottleneck imposed by human limitations.

AI doesn't have that limitation.

---

The Compounding Effect

Here's what excites me most:

Those 12+ memory episodes we created during this build? They're not throwaway notes. They're permanent organizational knowledge.

Next month, when we build the customer-facing dashboard, agents will search memory and find:

• How we structured the backoffice components
• What patterns worked for Permit.io integration
• Which approaches we tried and rejected
• The exact API conventions we established

The next build will be faster because this build made us smarter.

That's the compounding effect of organizational memory. Every project adds knowledge. Every agent contributes learnings. The organization gets smarter with every sprint.

Traditional teams lose knowledge when people leave, when documentation gets stale, when Slack threads get buried.

GUTT accumulates knowledge instead of dissipating it.

---

Try It Yourself

We're looking for teams who want to experience this shift:

What you need:

• A project that can be parallelized (most development work can)
• Willingness to work in plain English instead of detailed specs
• Claude Code or similar AI development tools

What GUTT provides:

• The memory layer that makes parallel agents coherent
• Context retrieval that works in real-time
• MCP integrations that connect your tools
• Knowledge capture that happens automatically

This isn't theoretical. We just built a full enterprise portal in an afternoon. No detailed specs. Just plain English and organizational memory.

The same approach works for any team with complex codebases and institutional knowledge worth preserving.

---

The Future of Development

Last week, I wrote about becoming a raccoon—adapting to AI-augmented development instead of fighting it.

This week, I'm showing what happens when you stop thinking about one developer + one AI and start thinking about orchestrated parallel agents + organizational memory.

The math is simple:

• 1 agent = 30x productivity improvement
• 6 parallel agents = 180x potential throughput
• Organizational memory = coherence across all of them
• No detailed specs = weeks saved on documentation

We're not at the end of this transformation. We're at the beginning.

The teams that figure out parallel AI coordination will outship everyone else.

GUTT is how you get there.

---

Ready to see parallel agents in action?

Book a demo

Learn more about how GUTT works.

---

Bart Van Spitaels is the founder of GUTT. He's spent the last week proving that AI-augmented development isn't about detailed specifications—it's about organizational memory that turns plain English into shipped software. This post was written while the gutt-backoffice portal runs in production.