Aedeon

The platform

One map. One plan. One verified change.

Aedeon is the system of record for how your software actually works, and the engine that evolves it. It reads every system you run, holds them in one living map, turns a sentence of intent into an executable plan, and performs the change with your team approving each gate.

Sign up Start free trial
Never trained on your code Runs in your cloud Your team approves every step
Live Graph → Supervisor → Evolve
15entity kinds
16relationship kinds
94–98%logic mapped
Map Plan & verified change Found in other systems

How the three connect

Three components, in sequence.

Aedeon Graph reads your systems and builds the map. Aedeon Supervisor reads the map and writes the plan. Aedeon Evolve runs the plan and verifies the result. Aedeon Studio is where your team does all of it.

Each hands its output to the next as a hard input.

Graph → Supervisor

Supervisor cannot plan against a system Graph has not mapped.

Supervisor → Evolve

Evolve cannot execute a step Supervisor has not planned.

Evolve → Your Git

Nothing lands in your Git that a person has not approved.

StageInputOutputWho approves
Aedeon Graph

Your repositories, databases, pipelines, cloud

A version-stamped map of every entity and dependency

Automatic, continuous
Aedeon Supervisor

Your intent, in a sentence, grounded in the graph

A step-by-step execution plan with an estimated cost

Your architects edit and approve the plan
Aedeon Evolve

The approved plan

The change, verified on production traffic, in your Git

Your architects and SREs approve every gate

The map

The living semantic map of how your systems actually work.

Aedeon Graph is the Code Intelligence Graph: a tenant-isolated, version-stamped knowledge graph of every system you run. It connects to your repositories, your databases, your pipelines and your cloud, parses your code the way a compiler does, and links what it finds across systems into one map. Every application, table, stored procedure, pipeline, integration and business rule, and how each depends on the others.

What it reads

Application code, databases and stored procedures, data pipelines and ETL, configuration, infrastructure definitions, and project context from tools like Jira, Confluence and Slack. COBOL and PL/I go into the same graph as Java, .NET, C++, Python, SAP ABAP and Oracle Forms.

Application codeDatabases & stored proceduresPipelines & ETLConfigurationInfrastructure definitionsJiraConfluenceSlack COBOLPL/IJava.NETC++PythonSAP ABAPOracle Forms

What it resolves

A syntax-level parser records that a method was called. Aedeon Graph records which method: which of five overloaded signatures actually resolves at that call site, which fields hold your data and every place they are read or written, the inheritance chains, the exception paths, the REST endpoints, the ORM mappings. Fifteen kinds of entity and sixteen kinds of relationship, linked across every file, repository and build dependency.

That difference decides whether a change is safe. What breaks if this changes. Who implements this interface. What reads this field. Those questions need edges that a syntax-level graph does not have.

One call site·five overloads

Aedeon Graph: one resolved call, followed across systems

Version-stamped by construction

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 affected subgraph. It keeps re-documenting your systems as they change, which is why it does not go stale the way a wiki does.

Tenant-isolated by architecture

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, in any form.

Re-stamp·only what changed
Affected subgraph · 4f3b9e2 Rest of the map · unchanged

Coverage, stated honestly

Aedeon Graph maps 94 to 98 percent of business logic automatically. The remainder is typically logic that never existed in code: operator knowledge, undocumented manual steps, and behavior that lives in a scheduler or a runbook rather than a repository. Aedeon Studio flags these as gaps in the map rather than filling them with a guess, and your team resolves them once. After that they are in the graph like everything else.

Coverage is the number to interrogate on a proof of concept. Connect one system, look at what the graph missed, and judge the product on that.

94–98% of business logic mapped automatically
Operator knowledgeFlagged as a gap
Undocumented manual stepsFlagged as a gap
Scheduler & runbook behaviorFlagged as a gap

Studio flags gaps instead of guessing.

The engine

From your intent to an executable plan.

Aedeon Supervisor is a proprietary planning model, pretrained on two decades of enterprise systems-engineering best practices: curated patterns, playbooks, and anonymized outcomes. Never on customer code.

It does one job. It converts your intent, stated in a sentence, into a step-by-step execution plan, then orchestrates the frontier models that carry each step out.

Supervisor·“Get us off Oracle.” → plan

One sentence in

“Get us off Oracle.”

Steps 4, 5 and 6 are the reason the graph exists. A tool reading the billing repository finds the schema, the queries and the ORM. It does not find the Python job in the operations repository, the compliance checks that run as database policies, or the dbt model in the warehouse. Aedeon Supervisor plans them because Aedeon Graph already mapped them.

Eleven steps out Plan
  • 01Translate schema and constraintsdb/billing/*.sqlBilling repo
  • 02Rewrite the rate-tier stored proceduresp_calc_rate_tier.sqlBilling repo
  • 03Rebind every ORM mappingservices/billing/orm/*.tsBilling repo
  • 04Repoint the nightly reconciliation jobops/nightly_recon.pyFound by Graph
  • 05Move two compliance checks into policydb/policies/*.sqlFound by Graph
  • 06Rewire the downstream BI feedwarehouse/dbt/models/billing.sqlFound by Graph
  • 07Port 11 Oracle-specific integration teststests/it/oracle_*.spec.tsBilling repo

Routing across frontier models

Supervisor plans; frontier models execute. Each task routes to the model that fits it, drawn from Anthropic, OpenAI, Google Gemini and xAI Grok, and limited to the models your organization has approved. If your security review clears two of the four, Supervisor plans within that constraint rather than around it.

Grounded in your graph

Every plan is written against the map of how your systems actually work. Supervisor does not plan from general knowledge about Oracle. It plans from your schema, your stored procedures, your dependency edges, at the versions the graph recorded them.

Routing·approved models only
Approved

Switch a provider off and watch the plan re-route

Why a proprietary model for this layer

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 Aedeon trained itself. Aedeon does not train general-purpose foundation models and does not compete with the providers it orchestrates.

Planning that compounds

Supervisor learns from the anonymized outcomes of every change it plans, never from customer code. Every system evolved improves the next plan, for every customer.

The change

The change, performed and verified.

Aedeon Evolve is the set of agents that execute the approved plan: updates, upgrades, replatforms, refactors, rewrites, retirements. Your architects edit the plan first. They add steps, change targets, reorder work. Nothing executes until a person approves the gate in front of it.

Three capabilities make Evolve safe for systems that run a business.

Evolve·amber: Oracle   green: Aurora

Citation-validated analysis

Every claim an agent makes has to cite the graph. “This rule enforces the credit limit.” “These seven services read this table.” Each assertion carries specific files, line ranges and schema objects, at specific versions. An assertion that cannot produce a valid citation is rejected before it reaches a plan step.

This is what stops the failure mode every engineering leader has already seen: an AI agent that is confidently wrong about a system it never fully read.

Claims·cite or be rejected

Verification on your real traffic

Before anything lands, the changed system runs against the old one on production traffic. Three classes of check run in parallel: data checks, application checks, behavior checks. Every response is compared. A divergence stops the gate, gets fixed, and the replay runs again.

On the New York Times evolution, 2,412,880 production requests were replayed and the gate opened at zero divergences.

Replay → compare → gate → ship. Nothing reaches production until the new system behaves like the old one.

Replay·old vs new, every response
0 requests replayed 0 divergences Gate · Closed

Full change history

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. Your CI/CD is included, whether that is Jenkins, GitHub Actions or Bamboo, and so is your infrastructure as code.

Your team owns all of it. If you stopped paying Aedeon tomorrow, the code, the history and the approvals stay in your repository.

A commit produced by Evolve  ·  carries trailers your auditors can read
commit 8c1f2ad  ·  aedeon-evolve[bot]  ·  billing/oracle-to-aurora
Evolve billing rate-tier logic from Oracle to Aurora PostgreSQL
Aedeon-Plan:
intent "Get us off Oracle."
Aedeon-Graph:
v2026.08.19 · 1,284 apps · 8,904 rules
Aedeon-Verified:
2,412,880 production requests replayed
Approved-By:
architect, SRE
Compliance-Diff:
SOX, no material change
SourceAnalysisModelApprovalsVerification runs

The workspace

One workspace for all of it.

Aedeon Studio is the interface to the platform. Your team explores the graph, expresses intent, reviews and edits plans, approves gates, and watches changes verify and land. Studio is how your team uses the three components rather than a fourth one.

Aedeon Studio  ·  Explore the graph billing-platform

Drag a node · click to inspect

Why this holds

A map of meaning, not a map of names.

Map of names · matched by string, stops at the file
Map of meaning · resolved across systems

Semantic depth

Most code-graph tools, including the open-source ones many AI agents are built on, parse syntax. They see class and method names, match calls by matching strings, and stop at the file boundary. Runtime-observation tools take the opposite approach and watch one application execute, which shows real behavior for the paths that happened to run and nothing about the paths that did not.

Aedeon Graph resolves meaning statically, across every system, at fifteen entity kinds and sixteen relationship kinds. A map of names can list your classes. It cannot answer the questions a change lives or dies on.

Planning that compounds

Tools that generate code do not get better at judgment. A planning model does. Every system Supervisor evolves improves the next plan, and the improvement comes from anonymized outcomes rather than from anyone's source.

The map becomes the record

Once the graph exists, version-stamped and current and yours, it is the system of record for how your software works. Every change after the first starts from it instead of from archaeology. That is why the second change costs less than the first, and why the tenth costs a fraction.

Clarifications

What Aedeon is not.

NotAn IDE assistant

Aedeon does not autocomplete your developers' code. It works at the level of whole systems.

NotA code generator

Aedeon does not build new applications from prompts. It changes existing systems safely.

NotConsultants with AI

Aedeon is a product and your team runs it. Hands-on delivery help is available through services partners, who contract and bill separately. Aedeon never bills engagement labor.

NotA foundation-model provider

Aedeon orchestrates frontier models and competes with none of them.

NotCloud-locked or database-locked

Any destination. No swapped lock-in.

Who uses it

The person who owns the systems.

The buyer is the VP of Applications, the VP of Engineering, or the CIO: whoever owns the systems and the budget to keep them current.

VP of ApplicationsVP of EngineeringCIO

Users do not 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.

Deployment

Inside your boundary.

Aedeon runs in a private VPC in your cloud, in a sovereign region, or fully air-gapped. Bring your own keys. Your graph, your source and every analysis stay inside your own tenant.

SOX, PCI and HIPAA impact diffs come with every change, so the audit trail gets stronger as your systems evolve. SOC 2, PCI DSS and HIPAA certifications are in progress.

Private VPC · sovereign region · air-gapped

Answers

Answers.

What is the Code Intelligence Graph?
It is a live map of how your systems actually work: fifteen kinds of entity and sixteen kinds of relationship, linked across every repository, database and pipeline, version-stamped and rebuilt as your code changes. It maps 94 to 98 percent of business logic automatically.
How is Aedeon Graph different from a code-search index?
A code-search index matches strings. Aedeon Graph resolves meaning: which overloaded method actually resolves at a call site, which fields hold your data and every place they are read or written, and how a stored procedure in one database connects to a dbt model in a warehouse. Those edges are what a safe change depends on.
What does Supervisor do?
Supervisor is Aedeon's proprietary planning model. Tell it what you want in a sentence and it converts that intent into a step-by-step plan grounded in your graph, then routes each step to the frontier model that fits it. Your architects edit and approve the plan before anything runs.
Do you train on our code?
No, in any form. There are no pooled indexes and no cross-tenant embeddings. Supervisor is trained on curated engineering best practices and anonymized outcomes only. Your graph, source and analysis stay inside your own tenant.
Which AI models does Aedeon use?
Aedeon orchestrates frontier models from Anthropic, OpenAI, Google Gemini and xAI Grok, limited to the ones your organization approves. Supervisor, the planning model, is Aedeon's own.
What does Evolve actually change?
Updates, upgrades, replatforms, refactors, rewrites and retirements. Your team approves every gate, every change is verified against the old system on your real traffic, and it lands in your Git with its full history attached.
What happens if a change breaks something?
It does not reach production. The new system runs against the old one on your real traffic first. Anything behaving differently is flagged, corrected and checked again before the change is allowed to ship.
What is not in the 94 to 98 percent?
Logic that never existed in code: operator knowledge, undocumented manual steps, and behavior held in a scheduler or a runbook. Studio flags these as gaps rather than guessing at them, your team resolves them once, and they join the graph.
Which systems can Aedeon read?
Application code, databases and stored procedures, data pipelines and ETL, configuration, infrastructure definitions, and project context from tools like Jira and Confluence. COBOL and PL/I go into the same graph as Java, .NET, C++, Python, SAP ABAP and Oracle Forms.
Is Aedeon Studio a fourth component?
No. Studio is the interface to the three. Your team explores the graph, expresses intent, edits plans and approves gates there.
Can Aedeon do an Oracle to PostgreSQL evolution?
Yes, and it is the change Aedeon is best known for. Schema, queries, stored procedures and ORM bindings are translated, every dependent system is found first, and the result runs against the old system on production traffic before cutover.
How long does a first change take?
Connecting one system and watching the graph build takes about an hour. A first production change typically lands inside a quarter. The New York Times evolution ran twelve weeks end to end.
Who owns what Aedeon produces?
You do. The code, the graph, the analysis, the approvals and the verification runs all live in your tenant and your Git.

Start here

See your systems mapped.

Connect one real system and watch the graph build. Then describe one change and see what comes back.

Book a demo Start free trial
hello@aedeon.ai