I built a complete AI platform. Then I realized I was at the wrong altitude.
TL;DR: I built a platform with 45 agents, 9 pre-commit phases, and 4 validation layers for zero users. When I audited honestly, I found a forgotten repo with 3 Python scripts that already solved the real problem. This is the story of the gap between platform altitude and problem altitude.
The numbers that made me uncomfortable #
| Metric | Value | What it means |
|---|---|---|
| Registered agents | 45 | 24 active, 21 orphaned or duplicated |
| Pre-commit phases | 9 | Gitleaks, typecheck, doc-drift, evidence-gate, vocab guard |
| Doc validation layers | 4 | SSOT drift, doc proliferation, file intelligence, evidence gate |
| Supabase tables with RLS | 8+ | Entity graph, wiki pages, timeline, gem discoveries |
| Paying customers | 0 | Zero. None. Nothing. |
| Real users | 0 | I was the only user of my own system. |
The complexity scale from the audit: Level 0 = Checklist plus prompt. Level 2 = Flow with human approval (pipeline: transcription, review, delivery). Level 4 = Multi-agent with 45 agents, native governance, self-healing. EGOS was at level 4. The first real problem I needed to solve was at level 2. Ratio: 10:1.
Why this keeps happening #
Karpathy has a simple principle: abstraction only after the third repetition. Before that, you are inventing complexity the problem did not ask for. When you love systems, the system itself becomes the work. The pre-commit hook becomes the objective. Governance, which should be a means, becomes the product. Of 1189 commits in 60 days, 44% were documentation and governance. The antidote: always measure complexity-built divided by complexity-encountered. Aim for 1:1.
What I found in the forgotten repo #
While auditing the kernel, I found a repo I had forgotten: a pipeline for police investigation work in Minas Gerais, Brazil. No sophisticated governance, no 45 agents, just three Python scripts running on real criminal cases. The pipeline: audio (MP4 or OGG) goes through transcription via Groq Whisper, then witness statement formatting, then generation of official DOCX documents with institutional letterhead. Two real cases processed, seven witnesses transcribed, 15 pytest tests passing. No agents. No event bus. No database migrations. And it solved the real problem.
What changed #
The platform is not shrinking. The kernel stays, with Neo4j holding 83 million nodes, Guard Brasil detecting 16 Brazilian PII patterns in 4ms, and a knowledge base system with compiled wiki. What changes is the order in which things reach users. Before: build first, validate later, or never. Now: validate first, build what the field asks for.
What actually works today #
| System | Status | Proof |
|---|---|---|
| Guard Brasil API | Live, 4ms p95 | curl https://guard.egos.ia.br/health |
| Police pipeline | 15 tests, 2 real cases | cd policia and run pytest |
| Gem Hunter | 14 sources, weekly cron | gemhunter.egos.ia.br |
| Timeline publishing | Articles, auto-draft via LLM | You are reading one now |
The pipeline that was already working #
The forgotten police pipeline had four stages. First, audio files in MP4, OGG, or M4A format are transcribed via Groq Whisper large-v3. Groq handles auto-segmentation for files over 25MB. Second, the transcript is formatted into an official witness statement summary (OVM format, a standard Minas Gerais police document). Third, a service communication is generated using the institutional template with official letterhead, headers, and seals. Fourth, a DOCX file is delivered, ready for the precinct record.
None of this required agents. The Groq transcription API handles the heavy lifting. A Python script handles the formatting. The institutional template is just a .docx file. The entire pipeline is a Makefile with four rules. That is the right altitude for this problem.
The code that published this article #
This article was published using the pipeline built in the same session where this diagnosis happened. The article-writer.ts agent generates drafts via LLM (qwen-plus), runs a Guard Brasil PII check, and inserts into the draft table. Publish moves it to timeline articles and syncs to the knowledge base. The irony is not lost: the platform that was at the wrong altitude built the tool that documented the lesson.
What did not work #
- Governance as the product: 44% of commits in governance. The accountability system became accountable to itself.
- Agent count as a metric: 45 registered, 21 unused. Volume is not capability.
- No external users: five weeks of development, zero people outside the project using anything.
- Premature orchestration: level-4 infrastructure for a level-2 problem. The ratio should have been 1:1.
Open questions #
- How do you measure the right altitude before building, not only after the audit?
- What is the minimum viable governance for a solo project with real users?
- When does a forgotten repo with 3 scripts become the thing you should have built first?
Files referenced in this article #
- agents/agents/article-writer.ts — the agent that published this article
- github.com/enioxt/egos — full kernel source, MIT license
Related in EGOS #
- Guard Brasil: 16 Brazilian PII patterns in 4ms — the system built after finding the right altitude
- Documentation lies. Here is how we built a verifier. — checks whether documentation is still true
Open source. Everything here is available at github.com/enioxt/egos. If you are building something similar or want to apply this in your context, reach out on X: @eniorocha_. Building in public.