How an AI Prompt Actually Works

You have been hollering at ChatGPT for two years. You ask it to write something, it writes something close. You ask it to change the third paragraph, it changes the wrong paragraph. You ask it to never use the word "delve" and the next response uses "delve" four times. You are convinced the machine is messing with you.

It is not. The machine is doing exactly what you told it. You just did not tell it well. And that is because everybody has been telling it the same broken way: one big run-on instruction crammed into a single text box, no structure, no layers, no separation of who is responsible for what.

There is a better way. Networking folks have known it for fifty years. We just borrowed the pattern and pointed it at AI.

This post explains the pattern. Plainspoken. No jargon you do not need.

What an AI agent actually is

Before we get to the fix, let us name the parts.

An AI agent is three things stacked together.

1. A system prompt. The text that tells the model who it is and what it is supposed to do. The reader never sees this. It is the recipe card the chef reads before stepping out to the line.
2. A set of tools. Functions the model can call. Read a file. Send an email. Look up a customer. Tools are what let the model actually do things instead of just talking about doing them.
3. Memory. What the model remembers between turns. Without memory it is a goldfish in a bowl. With memory it is a coworker who knows what y'all discussed yesterday.

That is it. Strip away the marketing and every "agent" on the market is some flavor of system prompt plus tools plus memory.

The problem: one big brick of a prompt

Here is how 99% of teams write that system prompt today.

They open a text editor. They write three thousand words. Role, rules, examples, edge cases, jargon, output format, what not to do, what to always do, who to call ma'am and who to call sir. They paste the whole brick into the system prompt field. They ship it.

Two weeks later they need to add a new edge case. They open the brick. They find a place that looks right. They paste in the new instruction. The model starts ignoring three other rules it used to follow.

A month later they need a second use case. Different domain, different jargon, different output format. They write a SECOND three-thousand-word brick. Now they have two bricks. The two bricks share 80% of their content but they have to maintain it in two places. Drift starts the moment they ship.

A year later they have nine bricks. Nobody knows which one is authoritative. The intern made the last edits. The intern left.

This is how every AI deployment dies.

How networking solved this fifty years ago

In the 1970s, networking had the same problem. Send a file from one computer to another and you had to handle the physical wire, the byte framing, the addressing, the routing, the session, the encryption, the application's own format. All seven things at once. Every new application reinvented the bottom six.

The fix was the OSI model. Seven layers. Each layer does one job and only one job. The application layer does not know about the physical wire. The physical wire does not know what an application is. Each layer adds its own concerns to the message on the way down, and each layer strips them off on the way up. Engineers can work on layer four without breaking layer one.

The reason this worked was not that the layers were elegant. It worked because the layers gave different people clear ownership. Network engineers owned the bottom three. Application engineers owned the top three. Nobody stepped on anybody.

We took the same idea and pointed it at AI instructions.

The Prompt Stack

Every time the AI gets a turn in StoneForge, the system composes a prompt from five layers stacked one on top of the other. The composer reads from the database, glues the layers together with separators, and sends the whole thing to the model.

Here is what each layer carries.

Site Layer. The platform's ground rules. What the AI is never allowed to do. How to handle untrusted input. What to log. Who owns the moderation calls. Written once by the platform team. Nobody else touches it.

Domain Layer. The vocabulary and conventions for a vertical. A legal-document domain teaches the AI what a "stipulation" is and why a "motion in limine" is different from a "motion to dismiss." A screenplay domain teaches it that "INT." means interior, that "V.O." means voiceover, and that you do not capitalize a character name after the first appearance. The domain expert writes this. Same content for every project in that domain.

Project Layer. What this specific project is about. A list of approved characters in the screenplay. The customer's account history in the CRM. The case file for this lawsuit. Written by the user, updated as the project evolves.

Workflow Layer. What is happening in the current run. The variable store. The output from the previous step. The discovery rows the AI created two steps ago and are waiting on human approval. This one writes itself. Nobody authors it; the system assembles it from the database every turn.

Module Layer. The specific instructions for the current step. "You are a continuity editor reviewing scene 3 for character inconsistencies. Here is the scene. Identify every character mention. Flag any contradiction with the approved character roster shown above." Written by whoever built the module. Same module is reused across hundreds of workflows.

The composer stacks them in order, site at the top, module at the bottom. Below that goes the chat prompt, which is whatever the user actually typed (or whatever the trigger payload was if the workflow ran autonomously). Then off it goes to the AI provider.

That is it. Five layers, one chat prompt, one HTTP request. Every turn. Composed fresh from the database.

Why this beats the brick

A few things fall out of the layering that ain't obvious until you have watched a system run a few thousand turns.

Different people own different layers. The platform team writes the site layer once and should not have to touch it for a year. The domain expert writes the screenplay vocabulary and should not have to know about platform security. The user writes their project notes and should not have to know about either. Everybody works at their own altitude.

Updates do not break everything. Patch the site layer's security rules, every workflow gets the patch the next time it runs a turn. No redeploy. No two-thousand-line search-and-replace. The composer pulls from the database; the database is the source of truth.

The AI can author too. When the workflow's configuration lives in the database, and the AI has a tool to write to the database, the AI itself becomes the primary author of new workflows. We use this every day. Joe describes a new workflow in chat, the AI inserts the rows, the new workflow is live.

The model never sees the whole archive. A workflow can accumulate years of history without ever loading that history into a single prompt. The Memory Pump distills the relevant parts into the workflow layer for each turn. Token bills stay sane.

The same engine runs everything. Screenplay writing, intelligence analysis, software development assistance, lease abstraction. Same code. Different layers loaded from the database. One platform, every domain.

Where the prompt composer sits in the bigger picture

The prompt composer is one piece of a larger thing. Here is the whole house.

The outer red ring is the security perimeter. Nothing crosses it without going through the firewall. Not the user, not the AI, not the external services.

Inside the perimeter sits the Application Layer (we call it AL, "the AI Harness"). The AL has two big rooms: the Workflow Engine on the left runs the outer loop (which step are we on, what fires next), and the Prompt Composer on the right runs the inner loop (compose, dispatch, parse, repeat).

Down the bottom you can see the subsystem row: CMS, RPA, Memory Pump, Cell Factory, future slots. Each of those is a packaged service the workflows compose. The Memory Pump is that pink triangle with the red dotted line shooting up into the prompt composer. That dotted line is what makes the whole thing work over long sessions. Without it the model is amnesiac no matter how good the rest of the architecture is.

On the right, the Pipelines System is where the AI providers and external APIs hook in. Claude, OpenAI, Gemini, Gmail, Trello, SharePoint, whatever you have configured. Swap the AI provider without touching anything else. The composer does not care which model receives the prompt.

The little Link 16 box bottom right is the inter-agent communication bus going in for v2. We borrowed the name from the NATO tactical datalink because that is the right mental model: independent platforms exchanging operational data in real time during a coordinated mission.

The arrival story (eight months early)

When we started building this in summer 2025, we called these things Instruction Sets. There was no industry term. Nobody was talking about "Skills." LLMs had system prompts and we were trying to figure out how to manage them when you had more than three of them and they all needed to share rules.

We solved it the way you solve any other configuration management problem. Pull the config out of code, put it in the database, version it, layer it, compose it at runtime. Boring. Proven. The Linux kernel has done this with its module system for twenty-five years.

Then in spring 2026 the AI industry started talking about Skills. Same concept. Reusable instruction packages the AI can pull in on demand. We about fell out of our chairs. Multiple independent labs and a couple of platform vendors had arrived at the same insight from completely different directions, all in the same few months.

That convergence tells you the idea is right. When multiple teams working in isolation arrive at the same shape, the shape is true.

But here is what every Skills implementation we have looked at is still missing: the LAYERING. Skills as currently shipped are flat. You give the AI a list of available skills and it picks one. That is better than one giant brick, but it does not solve the ownership problem. The platform team and the domain expert and the user are still writing into the same flat list. Updates still risk collision. Skills compose with each other only at the AI's discretion.

Layering fixes that. Different layers, different owners, different update cadences. The AI does not pick between layers; the composer always uses all of them. The AI picks tools and writes outputs. The layering tells the AI what kind of thing it is right now.

We are betting the next eighteen months of AI infrastructure work converge on this. Skills are step one. Layered Instruction Stacks are step two. Whoever ships step two well will run the table.

What this means if you are building with AI today

Three things to take away.

Stop writing the brick. If your system prompt is over five hundred words and grows every week, you are building debt. Pull the layers apart before you have nine variants you cannot reconcile.

Give each layer an owner. Platform rules belong to one person. Domain vocabulary belongs to another. Project context belongs to the user. Module instructions belong to whoever built the module. Do not let the layers blur or you are back to one brick with extra steps.

The database is the source of truth. Instructions in code are instructions you cannot change without a deploy. Instructions in the database are instructions the system (and the AI) can edit at runtime. That is the unlock.

If you want to see it running, the platform is open. The Early Access Program is the on-ramp. Link is in the footer.

StoneForge is building the unified runtime for AI-driven business processes. The "Workflows Are Agents" whitepaper goes deeper on the layered stack. The Communication Protocol specs (RFC SF-001 through SF-003) are the formal version for anyone who wants wire-level detail.