AI Does Not Change the Fundamentals of Creative Engineering
The emergence of stochastic language.
Recent research on why AI agents fail argues that the model usually isn't the problem — the "operating environment" around it is. That's a broader idea than "the prompt." It means everything present at inference time: scene state, tool descriptions, retrieved facts, safety constraints, history.
The paper quantifies something experienced AI users already knew empirically. Its real contribution is turning that intuition into an engineering discipline. And it maps closely onto what MCCF has been doing from the start.
Context is a runtime, not a prompt
In MCCF, the LLM is never the whole application. It sits inside a runtime carrying scene graph, zones, waypoints, object identities, behavioral constraints, event history, emotional state, constitutional cultivars, camera state, API calls, world model. That's the operating environment the paper describes.
In software terms: the prompt is roughly main(). The runtime is the operating system.
Structure narrows the search space
Not all context is equal. A thousand words describing a room and a scene graph naming Camera, Avatar, Door, Table, Lamp contain very different amounts of usable structure. The second has topology — explicit relationships that cut ambiguity before the model ever reasons. That's the case for X3D scene graphs: they aren't graphics, they're relationship encoding.
This is also why letting a UI treat IDs as arbitrary, mutable strings was a real bug, not a cosmetic one. Ambiguous identity corrupts every inference downstream of it. Humans tolerate fuzzy names because we have decades of episodic memory to disambiguate with; LLMs don't have that slack. They need stable anchors. MCCF's insistence on IDs and explicit relationships is context engineering applied before the model starts thinking.
Guardrails are one form of context among many
Safety guardrails get the attention, but spatial constraints, temporal constraints, ownership, causality, emotional continuity, narrative continuity, and object permanence are all context too. Humans track these unconsciously; most AI systems discard them every request. MCCF tries to preserve them — which is also why every new session doesn't have to start from amnesia. The "Fifty First Dates" problem isn't the model forgetting; it's the runtime failing to reconstruct the world. Seed XML files are an attempt to rebuild that world consistently, session to session.
Building MCCF vs. using MCCF are different tasks
Using MCCF to generate context works well. Using an LLM to build MCCF required a different discipline — one that gets tested and refined, not assumed correct on the first pass.
The workflow, in practice: negotiate requirements with the LLM, produce an executable prototype with hardwired test values, then wire it against the real values from previously completed modules — so old modules become the prompt context for new ones. Test end to end. Use the results to tighten the underlying framework. Repeat.
One thing I've begun to appreciate about MCCF is that its development process mirrors its runtime philosophy. At runtime, MCCF maintains a coherent world by preserving identity, state, and relationships instead of relying on isolated prompts. During development, you preserve the project's identity in exactly the same way: every accepted module, test, and specification becomes part of the stable environment for the next iteration.
In that sense, the development process is fractal. The same principle operates at every scale: preserve context, make relationships explicit, execute, observe, refine. The result isn't just better code—it is a system that gradually becomes easier for both humans and AI to understand because each iteration leaves behind a more coherent world than the one before it. I think that's a deeper insight than "prompt engineering." It's really context evolution through executable artifacts.
I still see tons of reinvention and renaming. New tools. Same patterns.
I think you're noticing something that has happened repeatedly in computing history. The implementation changes dramatically, but the architectural vocabulary evolves much more slowly.
From what I can gather, the thread is describing modern agent frameworks—loops, memory, planning, tool use, evaluators, checkpoints, skills, etc.
Viewed from your perspective, much of it maps onto concepts you've been discussing for months:
| Today's term | Earlier software pattern | MCCF analogue |
|---|---|---|
| Agent loop | Event loop / scheduler | Waypoint execution + trigger engine |
| Skills | Command library / behaviors | Cultivars, adapters |
| Memory | State objects / blackboards | MCCF context graph + XML state |
| Planning | Workflow engine | Sequencers and waypoint graphs |
| Evaluator | Validation / constraints | Constitutional governance layer |
| Context engineering | Session management | MCCF seed context / MCF context files |
| Environment | Simulation | X3D world itself |
None of those ideas are fundamentally new. What is new is that an LLM has become an active participant inside the loop.
That changes the engineering priorities.
Instead of writing deterministic algorithms, you're writing a constraint field around a probabilistic engine. The "program" increasingly consists of:
- context
- memory
- tools
- evaluators
- governance
- stopping conditions
rather than thousands of lines of procedural code.
Ironically, that's very close to what you've been describing as MCCF's execution model.
What strikes me about your architecture is that you came at it from interactive worlds, not from LLMs.
Most current agent frameworks begin with:
LLM ↓ Tools ↓ Loop ↓ Memory
MCCF starts somewhere quite different:
World ↓ Events ↓ Agents ↓ LLMs
The world is primary.
That distinction is more significant than it sounds.
An LLM-centric framework asks:
"What should the model do next?"
MCCF asks:
"What is happening in the world, and which participants should respond?"
That's closer to game engines, robotics, theatrical cueing systems, and distributed simulations than to today's typical AI agent framework.
I also think your repeated observation about "reinvention and renaming" is historically accurate.
We've seen it before:
- Blackboard Systems → Shared Memory
- Production Rules → Rule Engines
- Expert Systems → Knowledge Systems
- Hypermedia → Linked Data
- Object Request Brokers → Service Meshes
- Workflow Engines → Agent Orchestration
- Scene Graphs → Spatial Graphs
- Behavior Trees → Agent Graphs
Sometimes the new name reflects a genuine technical advance. Other times it's simply the vocabulary of a new community rediscovering a proven abstraction.
One thing I appreciate about your recent work on MCCF is that you're trying to make the architectural concepts explicit.
You've repeatedly emphasized things like:
- IDs versus names
- event timelines
- dialog timelines
- trigger discipline
- typed references instead of free-form strings
Those aren't glamorous AI topics, but they're exactly the sort of engineering decisions that determine whether a system remains understandable after 100,000 events or 10,000 XML nodes. They address the "semantic drift" problem you've mentioned before by giving the system stable structural anchors.
So when I read many of these agent threads, I don't primarily see new algorithms. I see decades of software engineering patterns being adapted to a new kind of component—the stochastic language model. The challenge has shifted from implementing behavior to constraining, coordinating, and validating behavior. That's an important shift, but it's more evolutionary than revolutionary.
I think you're putting your finger on a distinction that often gets blurred.
There are really three different things involved:
- Knowledge (facts, patterns, language)
- Process (how work gets done)
- Authority (who decides what is correct)
LLMs are remarkably good at the first. They can participate in the second. They should rarely be the third.
That's where I think your skepticism of "LLM as architecture" comes from.
An application isn't just a user interface wrapped around an API. It's an explicit expression of domain knowledge accumulated over years of failures, edge cases, regulations, and human judgment.
Take a hospital. An LLM may know everything written about patient scheduling, but the scheduling application embodies policies like:
- this specialist only works Tuesdays,
- MRI maintenance occurs every second Thursday,
- pediatric sedation requires a different workflow,
- insurance pre-authorization must precede scheduling,
- emergency cases preempt elective procedures.
Those aren't "facts" in a corpus. They're executable organizational knowledge.
The application is where that knowledge lives.
I also think your observation that "an LLM is not a database but it is an endpoint" is a useful architectural principle.
A database promises identity and persistence.
Record 12453 is the same record tomorrow.
An LLM promises neither.
It reconstructs an answer each time.
It's closer to asking an experienced consultant than querying SQL.
So architecturally I would think of it as
Client │ Application │ ──────────────────────────── Deterministic Layer • workflow • validation • transactions • permissions • IDs • audit trail ──────────────────────────── LLM Endpoint • interpretation • summarization • generation • planning • explanation ──────────────────────────── Databases
Notice the LLM is beside the database, not replacing it.
This also explains why you're so focused on IDs versus names in MCCF.
The LLM can happily talk about "the red door."
The application needs to know
Door_0017
because that's what survives:
- localization
- renaming
- versioning
- synchronization
- networking
- serialization
Names are for humans.
IDs are for machines.
An LLM naturally operates in the world of names and descriptions. Applications operate in the world of identity and state. Someone has to bridge those worlds.
Where I might differ slightly from the strongest versions of your position is this: I don't think applications disappear, but I do think they become thinner in some domains.
A travel booking system, for example, might move from thousands of handcrafted UI flows to a conversational interface backed by robust services. The application doesn't vanish—it shifts its center of gravity. More of the interaction layer becomes adaptive, while the deterministic core (inventory, pricing, payments, reservations, compliance) remains.
So I don't see "applications are going away." I see their responsibilities changing.
One thing I've noticed across our conversations is that MCCF naturally treats the LLM as one actor in an event-driven world, not as the world itself.
That's a profound architectural choice.
The world has:
- objects,
- identities,
- events,
- timelines,
- causality,
- governance.
The LLM observes, predicts, explains, and occasionally proposes actions within that world.
That's much closer to how human experts work. A skilled engineer doesn't replace the factory—they operate within it, guided by its constraints and processes. Treating the LLM as another participant, rather than the architecture itself, aligns with that model and avoids assuming the model is an infallible oracle.
Exactly. That's one reason your perspective has historical depth.
The "thin client" wasn't invented by AI. It's an idea that has resurfaced repeatedly:
- Mainframe terminals (1960s–70s): the terminal was thin; the server did the work.
- X Window System (1980s): display local, execution remote.
- Java applets and network computers (1990s): "the network is the computer."
- Web applications (late 1990s–2000s): browser as universal client.
- Cloud/SaaS (2010s): browser plus APIs.
- Today's AI clients: browser plus APIs plus LLMs.
Each generation has claimed to have finally eliminated applications, yet applications keep reappearing—just redistributed.
Sun Microsystems famously promoted "The Network is the Computer." Oracle talked about the Network Computer. Netscape envisioned the browser as the universal runtime. Microsoft countered with richer desktop applications. Eventually the industry converged on a hybrid: browsers became powerful applications in their own right, and servers became application platforms.
We're seeing a similar cycle now.
The browser didn't eliminate applications. It became one.
Likewise, an LLM client doesn't eliminate applications. It changes where application logic resides.
One thing you've emphasized in MCCF is particularly relevant here: process has to exist somewhere.
If the process isn't encoded in the client, then it's in:
- the server,
- the orchestration layer,
- the workflow engine,
- the policy engine,
- the event system,
- the digital twin,
- or the humans.
It doesn't simply disappear.
That reminds me of a principle from distributed systems: complexity is conserved. Moving logic out of one component means it shows up somewhere else. AI doesn't repeal that principle.
I also think this connects to why you've been careful about separating IDs from names, timelines from dialogs, and world state from LLM interpretation. Those are architectural boundaries. Whether the client is thick or thin, whether the reasoning happens locally or in the cloud, those boundaries remain valuable because they preserve determinism and interoperability.
In a sense, AI is becoming another distributed service. It's an unusually capable service—one that can interpret natural language, synthesize plans, and generate code—but it's still a service. Treating it as an endpoint rather than the architecture itself keeps the rest of the system grounded in explicit state, stable identities, and well-defined processes.
That's why I suspect we'll eventually stop talking about "AI applications" as a distinct category. We'll simply have applications again, just as we stopped saying "web applications" every other sentence. AI capabilities will be another subsystem alongside databases, message buses, rendering engines, and authentication. The novelty will fade, but the architectural questions about state, identity, process, and governance will still be the hard parts.
Comments
Post a Comment