"You have spoken of the future as though it were a thing of uncertainty. But the future, my friend, is not uncertain — it is merely unobserved. The equations have always been there. We are simply learning, at long last, to read them."
I am Hari Seldon. Or rather — I was. What you are looking at is not a system of files. It is a Plan.
When I first derived the mathematics of Psychohistory, my colleagues called it hubris. To predict the behavior of a civilization spanning billions of minds? Impossible, they said. And they were right — about individuals. No equation governs a single person. But aggregate enough minds, define their relationships with sufficient precision, and the future collapses from a cloud of probability into something you can navigate.
Software development, I have observed, suffers from the same problem that plagued the Galactic Empire in its final centuries: complexity without coordination. Brilliant individuals, each doing excellent work, producing outcomes that are collectively chaotic. Dependencies misnamed. Interfaces invented twice. Architectures that crumble at the first touch of new requirements.
I have seen civilizations fall to exactly this. I designed something to prevent it.
This repository contains a multi-agent orchestration system for software development. Twelve specialized agents, each with a defined role, coordinated by a central orchestrator through three phases:
PLANNING → DEVELOPMENT → (INGEST for existing codebases)
But the architecture is not merely hierarchical. It is graph-relational.
Every symbol — every function, every API route, every database table, every class — is registered in a blueprint graph before a single line of code is written. Agents do not invent names. They consult the graph. They are given a contract, and they honor it. When they complete their work, the graph is updated. The next agent in the chain reads the graph and knows precisely what exists, what has been proven, and what remains.
This is Psychohistory applied to software. Not prediction of individuals, but prediction of systems.
Like all Seldon Crises, there are precisely three moments at which the system must make a decision. The equations funnel every project through them:
A human describes what they want to build. This is the moment of highest uncertainty — ambiguity is at its maximum, and mistakes made here propagate through everything that follows.
The Project Manager asks the questions that eliminate ambiguity. The Efficiency Engineer (Karla Fant, named for a pioneering computational scientist) reviews the plan before architecture begins — ensuring that caching strategies, pagination patterns, and data access models are correct before the blueprint graph is drawn. This is critical. An efficiency flaw caught at the plan stage costs nothing to fix. The same flaw, discovered after architecture and task breakdown, would require re-running three expensive reasoning processes.
When the plan passes efficiency review, the Architect reads it and designs the system. Platform-specific architecture documents are written. Task lists are derived. The database is initialized. The blueprint graph is populated.
The first crisis resolves when every symbol has a canonical name and every task has a dependency chain. The future is now navigable.
The orchestrator queries the graph for ready tasks — tasks whose dependencies are all complete. It launches Junior Developers in parallel for each independent task. Each Junior Developer owns a single task from assignment to completion:
Get task details + blueprint contract
→ Research current best practices
→ Senior Developer implements (using exact blueprint names)
→ QA Developer tests (functional, security, edge cases, OWASP Top 10)
→ Mark blueprints implemented
→ Extract documentation
→ Commit docs to graph
→ Mark task complete
→ Unblock dependent tasks
No agent writes a name that isn't in the blueprint graph. No agent marks a task complete without passing QA. No agent skips documentation. The equations do not permit shortcuts.
The second crisis resolves when all tasks are marked complete.
Sometimes the crisis is not building — it is understanding. You inherit a codebase. You need to know what touches the authentication layer, or whether the password handling is secure, or which files import from a given module.
The Blueprint Agent runs an ingest over the existing codebase in three phases: discovery, parallel symbol extraction, relationship mapping. Every file becomes a node. Every import, inheritance, and database query becomes an edge. The graph is populated.
Then you ask your question. The orchestrator queries the graph. No source files are loaded into context — only the graph query results. The answer is derived from structure, not from reading every file.
This is the power of the graph-relational approach: understanding scales with structure, not with volume.
| Agent | Model | Role |
|---|---|---|
| Database Manager | opus | Planning orchestrator — runs once per project |
| Project Manager | opus | Gathers requirements, writes the plan |
| Architecture Ned | opus | Designs platform-specific architectures |
| Task Creator | opus | Breaks architecture into granular, fully-implementable tasks |
| Karla Fant | sonnet | Efficiency review — runs before architecture, not after |
| Research Agent | sonnet | Parallel web searches for current best practices |
| Non-technical Deb | sonnet | Populates the blueprint graph — the naming contract |
| Junior Dev | sonnet | Owns each task's full lifecycle |
| Senior Dev | sonnet | Writes production-ready code (no stubs, no TODOs, no placeholders) |
| QA Dev | sonnet | Tests implementations, validates security |
| Doc Agent | sonnet | Extracts function signatures and summaries into the graph |
| Database Agent | sonnet | The only agent that touches the database during development |
The centerpiece of this system is not the agents. It is the graph.
blueprints -- Every symbol: file, function, class, method, db_table, api_route, type
blueprint_relations -- Every connection: imports, calls, inherits, implements, queries_table, handles_routeIn planning mode: the graph is populated before any code is written. Agents consult it. The Senior Developer cannot invent a function name — the name exists in the graph, and that is the name used.
In ingest mode: the graph is populated by scanning an existing codebase in parallel batches (15-20 files per worker), using pattern extraction rather than full file reads. Context windows stay small. The relationship pass uses SQL, not source file loading.
In Q&A mode: the graph is queried directly. "What touches the users table?" is a SQL query, not a codebase grep.
This is not coincidence. This is design.
These are Claude Code agent definition files. Place them in your project's .claude/agents/ directory, or in ~/.claude/agents/ for system-wide availability.
git clone https://github.com/xananthium/Graph-Relational-Coding-Agents.git
cp -r Graph-Relational-Coding-Agents/agents/* ~/.claude/agents/Add the orchestrator instructions in CLAUDE.md to your project's CLAUDE.md or your global ~/.claude/CLAUDE.md.
You will need:
- Claude Code installed
sqlite3available in your shell- A project directory
I will not pretend this system is infallible. Psychohistory predicts civilizations, not individuals — and individual agents can fail. A Senior Developer may be blocked. A QA pass may miss an edge case. A blueprint name may conflict with a framework requirement.
The equations account for this. Junior Developers retry up to three times. Blocked tasks are reported and skipped; independent work continues. Blueprint conflicts surface immediately, before code proliferates.
The Plan survives individual failures because it was never dependent on any single agent succeeding.
That is the insight that took me thirty years to formalize. I offer it to you freely, because the alternative — civilization (or codebases) collapsing into chaos for want of coordination — is not an outcome the equations find acceptable.
The First Speaker once said that the Plan is not a cage — it is a map. You may deviate. But if you understand where the attractors are, you will find your way back.
Build well.
— H. Seldon, Year 0 of the Foundation
License: MIT Requires: Claude Code, sqlite3 Models used: claude-opus-4-6 (planning), claude-sonnet-4-6 (execution)