AGT and Foundry: a graph-native platform for agentic work
Why we built Agentic Graph Theory, and how Foundry turns it into production software.
Most platforms that claim to be "AI-native" are really just CRUD with a chat window pasted on top. You still model your domain as rows in tables. You still write controllers that map HTTP verbs to SQL. The AI is a guest in your architecture — it reads your database and writes back through the same APIs you built for humans.
That works until it doesn't. When an agent needs to reason across ten related entities, traverse a dependency graph, or recover from a failure that spans multiple services, the relational model becomes friction. The agent doesn't think in JOINs. It thinks in intents, states, and evidence.
That's why we built Agentic Graph Theory (AGT) — and why Foundry is built around it from the ground up.
What AGT actually is
AGT is a conceptual model for building software where the graph is not an afterthought. It is the primary execution surface. Business instances (orders, users, workspaces) live in the database as they always have. But knowledge about those instances — their relationships, inferred classifications, confidence scores, provenance — lives in the graph layer.
The graph is not a copy of your data. It is an interpretation of it.
Instance: what the business object is.
Node: what the system knows about that object in graph space.
This separation matters because it lets the graph evolve independently of the schema. You can add a new inference pipeline without migrating a table. You can attach telemetry to a node without polluting the instance. The agent reads the graph, not the database.
Reasoning tiers: not every decision needs a frontier model
AGT classifies execution into three tiers:
| Tier | What runs | Example |
|---|---|---|
| No reasoning | Static algorithms, UI handlers, API endpoints | "Generate a report from this template" |
| Low reasoning | Local models, bounded tasks | "Summarise this session's activity" |
| High reasoning | Frontier models, ambiguous problems | "Design a new feature from this spec" |
The key insight: reasoning is expensive, and most of your runtime shouldn't need it.
When an agent succeeds repeatedly at a task, AGT captures the stable pipeline and promotes it to a graph service — a deterministic, no-reasoning execution path registered as an intent edge. The system gets cheaper and faster over time as more algorithms graduate.
When a graph service fails, the failure is attributed to the specific edge that produced it. Hard evidence (deterministic test failure, schema violation) triggers immediate re-reasoning. Fuzzy evidence (model confidence dropped, flaky test) accumulates over a horizon. The service is demoted back to a reasoning tier only when the evidence demands it.
Sessions as the work surface
In Foundry, work happens in sessions. A session is a tree of blocks, each with a state machine. At any moment, a block exposes an intent surface — the set of actions it can currently accept. The agent (or the human) navigates by picking an intent and invoking it.
(block:idle) --[intent: start-process]--> (block:running)
Every successful navigation is measured. Every failure is attributed. Over time, the system learns which paths are stable and promotes them to graph services. The graph becomes a map of what the platform knows how to do — and how confidently it knows it.
This is not a chatbot. This is a platform that learns.
What this means for developers
If you build on Foundry, you don't write controllers. You write blocks — state machines that declare their intents, their state transitions, and their effects. The platform handles:
- Graph synchronisation: your entities automatically become nodes
- Intent registration: your block's actions become traversable edges
- Failure attribution: exceptions become graph evidence, not just log lines
- Algorithm discovery: repeated successful paths graduate to static services
- Re-reasoning: degraded services are automatically demoted for repair
You still own your data. You still own your code. But the platform owns the knowledge about how your code behaves — and uses that knowledge to make agents more reliable, more observable, and cheaper to run.
Why this isn't just another low-code platform
Low-code platforms give you pre-built blocks and hide the code. Foundry gives you the substrate for building agent-native software — and keeps the code visible, versioned, and yours.
The difference is in the model:
- Traditional platform: database → API → UI → agent reads UI text
- Foundry: database + graph → intent surface → agent traverses graph → human sees same surface
The agent and the human operate on the same structured intent surface. The agent doesn't scrape your UI. It doesn't guess your API. It traverses the graph the same way the UI renders it — because both are projections of the same underlying model.
Where we're going
AGT is still evolving. The core doctrines — property causality, content theory, algorithm discovery, failure attribution — are stable enough to build on. But the scoring function that picks the next intent? That's emergent. It is what the discovery loop is for.
We're building Foundry in the open because we believe the next generation of software platforms will be graph-native, agent-aware, and reasoning-conscious. If that sounds like the platform you want to build on, get in touch.