c0mpiled_
← back to articles
code·april 11, 2026·15 min read

Exocomp: What Happens When You Put the LLM Inside the Application

by james tan123 reads

Applications used to be defined by code — hand-written logic, fixed schemas, bespoke views. Exocomp inverts this: the LLM is the computational primitive, Postgres is its memory, the framework is the containment field that makes it safe and persistent. You don't build the app — you talk to it, and it compiles itself from the questions you ask.

Repository: github.com/Transpose-Platform/c0mpiled-ear

I've been building dashboards and data products for over a decade — financial platforms, CRM systems, knowledge bases, operational tools across healthcare, fintech, venture capital, and government. After all of it, there's one thing I keep coming back to: every single one of these systems is the same thing underneath.

The table names are different. The UI is different. The business logic is different. But the data model is always the same pattern: things that exist, what's known about them, and how they connect to each other. A patient in a hospital, a deal in a CRM, a task in a tracker, a paper in a research database — they're all the same structural object wearing different clothes.

In computer science, this pattern has a name: Entity-Attribute-Relationship (EAR). The idea goes back to the 1970s. It's an old idea, and I believe it's the most powerful general-purpose data abstraction we have. For the first time, there's a technology that can make it practical for everyone.

EAR: A Brief History

EAR emerged from medical informatics in the 1970s and '80s. Researchers needed clinical databases that could handle the extraordinary variety of medical data — without redesigning the schema every time medicine discovered something new to measure. The fix: instead of encoding the data structure in the schema, encode it in the data itself. One table for entities, one for attributes, with the type stored as metadata. The schema stays the same no matter what you're storing.

Add a relationship table — typed, directional edges between entities — and you get EAR. It's a graph database that fits inside a relational schema.

The pattern keeps getting independently rediscovered: RDF triples in the semantic web, nodes-and-edges in graph databases like Neo4j, Palantir's Foundry Ontology. Most developers reinvent it without knowing it — they design contacts, deals, activities tables and don't realize they've rebuilt EAR with domain-specific column names. The pattern keeps surfacing because the real world is genuinely structured this way.

The Overhead Problem

If EAR is the right abstraction, why isn't everyone using it explicitly?

Because the abstraction is easy. The overhead of making it useful is brutal.

At Palantir, deploying the Ontology required teams of forward-deployed engineers spending months on-site building ingestion pipelines, query layers, dashboards, and views. The pattern was universal — but every deployment was, in effect, a custom software project built on top of a generic substrate.

That's why EAR never escaped the enterprise. The cost of building around it was always the bottleneck. What was needed was something that could handle the overhead — query generation, visualization, API building, data extraction — without requiring a team of engineers.

The Inversion

Almost everything being built with LLMs today uses them from the outside in. Copilot sits beside your editor. ChatGPT sits in a browser tab. The application is the primary artifact, and the LLM is a secondary tool applied to its surface.

I think this is the wrong long-term architecture for what LLMs are actually good at.

Consider biocomputing. The neuron — messy, noisy, nonlinear — sits at the center of every biological intelligence system. But a neuron by itself is useless. Everything around it exists to make it functional: myelin insulates, the blood-brain barrier filters chemical inputs, the skull provides protection, sensory organs translate the chaotic external world into electrochemical formats neurons can process.

Quantum computing follows the same pattern. The qubit sits at the center, surrounded by cryogenic cooling, error correction, measurement apparatus. A powerful but unreliable core, surrounded by structure that makes it safe and useful.

That's the architecture exocomp uses for an LLM. The LLM is not a feature bolted onto a sidebar. It is the computational core, and everything else exists to make it useful.

┌────────────────────────────────────────────────────┐
│              UI / HTTP (Django)                    │
│  ┌──────────────────────────────────────────────┐  │
│  │           Renderers (14 types)               │  │
│  │  ┌────────────────────────────────────────┐  │  │
│  │  │       Safe Executor (sandbox)          │  │  │
│  │  │  ┌──────────────────────────────────┐  │  │  │
│  │  │  │        LLM (Claude)              │  │  │  │
│  │  │  │     computational core           │  │  │  │
│  │  │  └──────────────────────────────────┘  │  │  │
│  │  │   EAR schema     Saved Functions       │  │  │
│  │  │   (memory)       (learned tools)       │  │  │
│  │  └────────────────────────────────────────┘  │  │
│  └──────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────┘

The LLM can read any data, generate any query the executor allows, pick any visualization, create any function the sandbox can run. But it can't access the filesystem, can't make arbitrary network calls, can't break out of the namespace. The application is the containment field. The LLM is the reactor.

When the LLM is at the periphery, it can only do what the application's API exposes. When the LLM is at the center, it can do anything the constraint layer permits. The LLM isn't helping you build an app. The LLM is the app. Everything else is containment.

Tool Use, Inverted

Schick's Toolformer (2023) showed LLMs could call external tools. Anthropic and OpenAI productized it as function calling. Yao's ReAct (2022) formalized the reasoning-action loop that became the foundation for agents (LangChain, AutoGPT, CrewAI).

But all of these share something: the tools are always outside the model. The calculator is an external API. The function is defined by a developer and registered in a manifest. The LLM is a consumer of tools, not a producer of them.

Exocomp inverts this. The LLM doesn't call pre-built tools — it generates them. It writes parameterized Python functions, stores them in Postgres, and the framework executes them on future calls without involving the LLM. In the agent paradigm, a human builds the tools and the LLM decides when to use them. In exocomp, the LLM builds the tools and the framework decides when to use them.

The LLM compiles. The framework runs.

This means the system's dependency on the LLM is a trajectory, not a fixed state. Day 1, every query needs an API call. Day 30, most common queries execute from stored functions at database speed. Day 90, even routing is deterministic. The LLM's role progressively shrinks from "does all the work" to "handles novel cases and builds new tools." A compiler is used heavily during the build. It's rarely invoked at runtime.

The Exocomp

There's an episode of Star Trek: TNG where the Enterprise encounters the Exocomps — small robots that can analyze a novel problem, fabricate the specific tool they need, deploy it, and then build new tools for problems they haven't encountered before. They don't just use tools loaded into their programming. They manufacture their own from accumulated experience.

That's what happens when you embed an LLM inside an EAR schema with a safe executor and a persistence layer.

The first time you ask exocomp a question, the LLM does the hard work — reads the live schema, understands the question, generates a Django ORM expression, picks a visualization, executes it in the sandbox. Then it does what an Exocomp would do: it examines the query it just generated, recognizes the generalizable pattern, writes a parameterized function, and stores it in the database for reuse.

def count_by_type(entity_type_name):
    return [{"value": active_entities(entity_type_name).count()}]

Not count_companies(). A reusable tool with a parameter for the part that varies. Stored alongside metadata: match_criteria, param_spec, render_type.

The next time anyone asks "how many people?" instead of "how many companies?", the system doesn't invoke the LLM. It recognizes the intent matches a saved function, extracts the parameter, and executes the stored function from Postgres. Instant. No LLM.

After a week of use, you have the functional equivalent of a purpose-built application — except no one sat down and built it. It compiled itself, function by function, from the questions people asked.

It replicates its own tools. It's the Exocomp.

Four Tables

After more than a decade of building these systems, I can tell you with confidence: it always fits in four tables.

EntityType → Entity → Attribute
                ↕
          Relationship ← RelationshipType

Everything is an Entity. A person, a company, a funding round, a task, a weather observation — all rows in the same table, differentiated only by EntityType. There is no separate Event model. There's Entity, and the type tells you what it is.

Everything connects via Relationship. "Sam Altman leads OpenAI." "This task depends on that task." Same table, same structure. The RelationshipType carries the semantic meaning.

Attributes are temporal. Never updated in place. Each change creates a new row with a fresh timestamp. Want to know what OpenAI's valuation was in 2023? The row is still there. Full audit history is an inherent property of the schema.

I've watched this pattern hold across every domain — healthcare, finance, venture capital, operations, research. The schema doesn't know what you're storing. It doesn't need to. That's why Palantir was able to build a multi-billion dollar company on this abstraction. The question was never whether EAR was right. It was whether the cost of building around it could come down enough to make it accessible. The LLM brings that cost to near zero.

Four tables is the starting point, not the ceiling. As an application matures, specialized structures will emerge — materialized views for hot queries, audit tables for compliance. The key is that these derive from the EAR substrate rather than replacing it.

Why Postgres

If the data model is fundamentally a graph, why store it in Postgres instead of Neo4j? If the LLM is doing interpretation, why not a vector database like most RAG systems?

Simplicity in the tools begets an LLM that can manage complexity better. Postgres is boring in the best sense — decades of production hardening, reliable indexing, transactions, mature ORM support. Every developer knows how to operate it.

A graph database would mean a second storage system, a second query language, a second failure mode. A vector database gives you semantic similarity, but similarity isn't accuracy. When you ask "who leads OpenAI?", you don't want the five text chunks most similar to that question — you want to traverse a typed leads relationship from a Person entity to a Company entity and get an exact answer.

The cleverness belongs to the LLM. The reliability belongs to Postgres. Asking the LLM to also navigate a sophisticated storage engine would be like asking the qubit to manage its own cooling system.

What the LLM Does

Four categories of work that previously required dedicated engineering teams:

Ingestion. Paste unstructured text — meeting notes, articles, even bare URLs — and the LLM extracts entities, attributes, and relationships. "OpenAI raised $6B led by Thrive Capital at a $157B valuation" becomes three entities, temporal attributes, and typed relationships. No ETL. No schema mapping.

Querying. Natural language questions become ORM expressions, executed in a sandbox, rendered with the appropriate visualization from 14 types. The LLM doesn't just retrieve data — it decides how to present it.

Tool creation. When the LLM generates a query, it simultaneously writes a parameterized function and stores it in Postgres. Future queries that match execute the stored function directly. The LLM compiles itself out of the critical path.

External reach. When the answer isn't in the database, the LLM writes a function that calls an external API, stores the result as an EAR entity, and returns it for rendering. The function gets saved. The EAR schema becomes both knowledge base and cache.

Three Tiers of Execution

Not every query needs the LLM. The system checks three tiers in order:

TierMethodCostLatency1. DeterministicTemplated example match (how many {entity_type}), trigger patternsZero<1ms2. SemanticSentence embeddings (all-MiniLM-L6-v2) over saved function examplesZero~20ms3. Full LLMClaude conversation with tool_useAPI cost1-5s

The step-down is automatic. Day 1, everything hits Tier 3 — no saved functions exist. Day 30, the most frequent patterns match at Tier 1. The system's LLM dependency decreases with every question asked.

Six built-in functions ship with the framework — count_by_type, list_by_type, find_entity, get_attribute_value, filter_by_attribute, list_relationships, where_does_person_work — so universal CRUD queries work at Tier 1 from day one. The LLM only gets called for genuinely novel queries.

What Lives Where

A clean separation: the LLM handles all intelligence, Postgres stores all state, Python is pure plumbing.

  • In the LLM: routing, extraction, querying, function generation, view selection, API research
  • In Postgres: entities, attributes, relationships, saved functions (with their stored views), config (as EAR entities, not env vars), conversation history
  • In Python (~3,500 lines): safe sandbox, semantic matcher, renderers, HTTP plumbing

One prompt file drives all LLM behavior. Change the prompt, change the system. The Python doesn't make decisions — it executes what the LLM and stored functions tell it to do.

How People Would Use This

The founder who needs everything but has nothing. You're starting a company. You need a CRM, a task tracker, a knowledge base, a fundraising pipeline. You don't have time to evaluate five SaaS tools, and you don't know exactly what you need yet. You paste investor notes — Person and Fund entities appear, linked to your Company. You paste co-founder meeting notes — Tasks appear, linked to owners. Then you start asking questions. "Show me investors who expressed interest but haven't committed." The LLM writes the query, you get a table, the function saves. Within a single session, your CRM + task tracker + investor pipeline exists. It wasn't five apps from a marketplace. It was one schema that compiled its own query layer from the questions you asked.

The team building institutional memory. Every organization has knowledge in people's heads, in Slack threads that scroll past retention, in onboarding docs that are outdated by the time they're shared. Paste meeting notes, customer call summaries, post-mortems — the system extracts who said what, what was decided, what tasks were assigned. New team members ask the system instead of interrupting colleagues. The first person who asks "which customers are in healthcare?" causes the LLM to generate that function. Everyone who asks afterward — this week, next year — gets an instant answer from the stored function. The organization's recurring questions become its operational logic.

The Final Evolution

You can trace the stepping stones that brought us here, each moving the LLM one layer closer to the center:

  1. LLM as autocomplete (Copilot, 2021). Outside the application. Predicts the next token.
  2. LLM as conversation partner (ChatGPT, 2022). In a browser tab. You're the integration layer.
  3. LLM as agent (LangChain, AutoGPT, 2023). Calls APIs through the same interfaces a human would. Workflow frameworks reimplement the kind of control logic mature software infrastructure already handles.
  4. LLM as knowledge base (RAG, 2023-2025). Documents chunked and embedded. Similarity search with a chat interface. No schema, no typed relationships, no traversal.
  5. LLM as core computational primitive (Exocomp). The architectural inversion is complete.

In every previous step, the application is primary and the LLM is added to it. Exocomp inverts the relationship. The LLM is the primary computational element. The application exists to make the LLM useful: EAR for memory, executor for safety, prompts for translation, saved functions for persistent learned capabilities, renderers for output.

The application is the containment field. The LLM is the reactor.

I believe this is the direction the industry converges toward. Not exocomp specifically, but this pattern: a structured data substrate, a constrained execution environment, and a persistence layer that lets the LLM build the operational logic that would otherwise require a development team.

What This Isn't

I want to be honest about the limitations. The full list is in CRITIQUE.md. The ones that matter most:

  • EAR is slow for large data. Every query becomes a multi-join across Entity/Attribute/AttributeType. Materialized views are the mitigation path, but they're unbuilt.
  • Generated functions are unreviewed code. The sandbox is locked down, but the logic itself can still be wrong. There's no test suite for saved functions yet — though the framework now self-validates them on save and detects echo-output broken functions at runtime.
  • Entity extraction is imperfect. Names get inconsistently normalized. Dedup isn't built.
  • No authentication, no multi-tenancy. Currently suitable for personal or trusted-team use only.
  • The Exocomp metaphor has a gap. The system is reactive — it builds tools in response to questions, not proactively from observed patterns.

These are real, not theoretical. The question is whether the core pattern is sound enough that they can be addressed incrementally without changing the architecture. I believe it is.

Try It

Exocomp is open source: github.com/Transpose-Platform/c0mpiled-ear

git clone https://github.com/Transpose-Platform/c0mpiled-ear.git
cd c0mpiled-ear
./setup.sh
python manage.py runserver

Paste something. Ask something. Build something.

The first few minutes will be slow — the LLM is doing all the work. But watch the saved functions accumulate. By the end of your first session, most of the queries you commonly ask will execute instantly, served from stored functions at database speed.

Four tables for the domain. One LLM call to learn a pattern. Zero LLM calls to repeat it. The app compiles itself from what you ask it.

* * *