First it reads. Then it maps. Then it changes what you tell it to.
Most AI coding tools generate code and hope. Aedeon starts from a complete map of your systems — and ends with a verified change in your Git.
Graph
The living semantic map of how your systems actually work.
Graph — the Code Intelligence Graph — is a tenant-isolated, version-stamped knowledge graph of your systems. It connects to your repositories (GitHub, plus Jira, Confluence, Slack for context), your databases, and your cloud, and parses your code the way a compiler does — for every application, schema and stored-procedure models for every database — then links them across systems into one graph: every application, table, pipeline, integration, and business rule, and how they depend on each other.
Your graph, your source, and every analysis derived from them run in an isolated tenant. No pooled indexes, no cross-tenant embeddings, no training on your code.
Every node and edge carries the version of the source it came from — commit hash, schema version, pipeline revision. When your code changes, the graph re-parses and re-stamps. The map never goes stale, because it keeps re-documenting your systems as they evolve.
This is the map your enterprise has never had — and it's yours: it lives inside your tenant boundary and outlives any single change.
Supervisor
From your intent to an executable plan.
Supervisor — the Decision Supervisor model — is a proprietary, pretrained planning model, trained on two decades of enterprise systems-engineering best practices: curated patterns, playbooks, and anonymized outcomes. Never on customer code.
Supervisor does one job with precision: it converts your intent — "get this platform off Oracle," "rebuild this claims workflow as agents" — into a step-by-step execution plan, then orchestrates the frontier models to carry it out: Anthropic, OpenAI, Google Gemini, and xAI Grok, each task routed to the model that fits it, only among the models your organization approves. Graph is Supervisor's schematic layer — every plan is grounded in the map of how your systems actually work, not in general knowledge.
Why a proprietary model? Because planning is the judgment layer. Frontier models are excellent executors and interchangeable by design; the judgment about what to do, in what order, with what checks is the part we trained ourselves. We don't train general-purpose foundation models, and we don't compete with the providers we orchestrate.
Evolve
The change, performed — and verified.
Evolve is the set of agents that execute Supervisor's plan: updates, upgrades, replatforms, refactors, rewrites. Your architects edit the plan — add steps, change targets, re-order — and nothing executes without a human approving the gate.
Three capabilities make Evolve safe for systems that run a business:
Every claim an agent makes — "this rule enforces the credit limit," "these seven services read this table" — must cite the graph: specific files, line ranges, schema objects, at specific versions. An assertion that can't produce a valid citation is rejected, not shipped.
Before anything lands, the changed system is tested against the old one on production traffic — data checks, application checks, behavior checks. Mismatches are fixed and re-verified.
Every change lands in your Git with its complete provenance attached — the source it derived from, the analysis that justified it, the model that generated it, the approvals, and the verification runs — with your CI/CD (Jenkins, GitHub Actions, Bamboo) and infrastructure-as-code included. Your team owns everything.
Studio
One workspace for all of it.
Studio is the interface to the platform — where you explore the graph, express intent, review and edit plans, approve gates, and watch changes verify and land. It's not a separate component; it's how your team uses the three that are.
A map of meaning, not a map of names.
Most code-graph tools — including the open-source ones many AI agents stand on — parse syntax: they see class and method names, match calls by matching strings, and stop at the file boundary. Aedeon's graph resolves meaning: which of five overloaded methods is actually called, the fields that hold your data and every place they're read or written, inheritance, exception paths, REST endpoints, ORM mappings — 15+ kinds of entities and 16 kinds of relationships, linked across every file, repository, and build dependency. A map of names can list your classes. It cannot answer the questions a change lives or dies on: what breaks if this changes? Who implements this interface? What reads this field? Those answers require edges a syntax-level graph simply doesn't have.
Supervisor learns from the anonymized outcomes of every change it plans — never from customer code. Every system evolved makes the next plan better, for every customer. Tools that generate code don't get better at judgment; a planning model does.
Once the graph exists — version-stamped, current, yours — it's the system of record for how your software works. Every new change starts from it instead of from archaeology. It outlives any single change, and everything your team builds next builds on it.
What Aedeon is not.
- Not an IDE assistant.
It doesn't autocomplete your developers' code; it works at the level of whole systems.
- Not a code generator.
It doesn't build new apps from prompts; it changes existing systems safely.
- Not consultants with AI.
It's a product. Your team runs it. (Hands-on delivery help is available through services partners — billed by them, not us.)
The person who owns the systems.
The buyer is the VP of Applications, VP of Engineering, or CIO — the person who owns the systems and the budget to keep them current. Users don't need to write code to express intent and supervise a change; they need to know the end-state they want. Engineering teams review and own everything that lands.