Architecture on TurboVision

From Prompt to Protocol Stack

Sat, 18 Apr 2026 00:00:00 +0000

The future of AI control was never going to fit inside one clever paragraph typed into a chat box. What looks like prompting today is already breaking apart into layers, and each layer is quietly starting to serve a different audience: humans, agents, tools, infrastructure, and, eventually, other layers pretending not to be there.

TL;DR

Prompting is evolving into a full protocol stack. Natural language remains at the human boundary, while deeper layers increasingly carry schemas, tool definitions, memory layouts, compressed state, and possibly machine-native agent communication. The chat box survives, but it is no longer the whole machine.

The Question

Have you ever wondered whether we are still dealing with prompting at all once prompts become longer, more structured, and more system-like? Or are we actually watching a new software stack form around language models?

The Long Answer

I think we are very obviously watching a new stack form, even if the industry still likes talking as though everything important happens inside the visible prompt.

The Prompt Is No Longer the Whole Unit

The mistake is to imagine the prompt as the unit. That made some sense when language models were mostly single-turn text machines. It makes much less sense once we ask them to persist, use tools, collaborate, manage memory, or act inside workflows. At that point the useful object is no longer the prompt alone. It is the entire communication architecture around it.

That architecture already has layers, even if we do not always name them consistently.

At the top there is the human intention layer:

goals
tone
constraints
questions
examples

This is where natural language shines. It is flexible, compresses messy intention well enough, and lets humans stay close to the task without dropping into low-level syntax immediately.

Below that sits the behavioral framing layer:

system instructions
role definitions
safety boundaries
refusal rules
escalation behavior
evaluation priorities

This layer says less about the task itself and more about the posture the model should adopt while attempting the task.

Below that sits the operational context layer:

retrieved documents
repository state
conversation history
persistent memory
environment facts
current artifacts under edit

This layer answers the question: what world is the agent acting inside?

Below that sits the tool layer:

tool names
schemas
permissions
invocation rules
observation formats
retry and failure policies

Once a model can act, tools stop being optional flavor and become part of the language of control.

Below that sits the machine coordination layer, which is still young but increasingly visible:

compressed summaries
state snapshots
cache reuse
structured intermediate outputs
inter-agent messages
latent or activation-based exchange

This is the layer where ordinary prompting begins to blur into protocol engineering.

And beneath all of that, of course, sits the model-internal representational machinery itself.

If you lay the system out this way, a lot of contemporary confusion evaporates. People argue about prompting as though it were one thing. It is not. They are usually talking past each other about different layers and then acting surprised that the debate goes nowhere.

One person means phrasing tricks in the user message. Another means system prompt design. Another means retrieval quality. Another means JSON schemas. Another means agent orchestration. Another means activation steering.

All of those are “prompting” only in the broadest and least useful sense.

The Layers Are Already Visible

That is why I prefer the phrase protocol stack. It captures the architecture better and also suggests the future more honestly. It sounds less magical, which is exactly why I trust it more.

A mature AI system will likely look something like this:

human gives high-level intent in natural language
system translates that intent into a stabilized task frame
task frame binds relevant memory, documents, and tool affordances
one or more agents execute subtasks under explicit protocols
agents exchange summaries or compressed state internally
final result is reprojected into human-legible language for review or approval

Notice what changed. Natural language remains important, but it is no longer the whole medium. It becomes the topmost interface over deeper coordination channels.

That is exactly how most successful technical systems evolve.

A web browser gives you a page, not packets. A database query gives you SQL, not disk head timing. An operating system gives you processes, not transistor switching.

The user gets a legible abstraction. Underneath, layers proliferate because raw freedom does not scale by itself.

The AI case is especially interesting because language appears at both ends of the stack. We enter through language, we leave through language, and the machinery in the middle gets less and less obligated to stay conversational.

At the entrance, language captures goals. At the exit, language communicates results. In the middle, however, language may become increasingly optional.

That is where agent-to-agent communication becomes important. If two agents are solving a problem together, full natural-language exchange is often expensive. It is verbose, ambiguous, and tied to human readability. For some tasks that is still worth it, especially when auditability matters. For others it may prove wasteful compared to compressed intermediate forms.

There is something faintly ridiculous in imagining two high-speed reasoning systems politely sending each other mini-essays in immaculate English simply because that is the only style of interaction humans currently find respectable. A lot of the future may consist of us slowly admitting that the internals do not actually want to be this literary.

We are already seeing small previews of this future:

structured chain outputs instead of free prose
schema-constrained responses
tool-call argument objects
reusable memory summaries
vector-based soft prompts
activation steering
experimental latent communication between agents

These are not isolated hacks. They are early pieces of a layered control model, even if the marketing language around them still prefers the friendlier fiction that we are merely “improving prompting.”

Natural Language Becomes the Top Layer

A useful way to think about it is with a networking analogy, and yes, I know that analogy is a little nerdy. It is still better than pretending the chat transcript is the architecture.

Human prompting today often behaves like application-layer traffic mixed together with transport, session, and routing concerns in the same blob of text. That is why prompts become huge and fragile. They are doing too many jobs at once. They describe the task, define policy, encode examples, specify output shape, explain tool behavior, and sometimes even embed recovery instructions.

Anyone who has seen a “simple prompt” mutate into a 900-line system prompt with XML-ish delimiters, output schemas, tool instructions, refusal clauses, and five examples knows exactly how fast this happens. The thing still lives in a chat window, but it stopped being “just chatting” a long time ago.

In a more mature stack, those concerns separate.

The result should not be imagined as less human. It should be imagined as more disciplined. Humans still speak their goals in language, but the system no longer forces every single control concern to be expressed as prose in one monolithic block.

This matters for engineering quality.

Once layers separate, you can version them independently. You can test them independently. You can reason about failure more clearly. You can update tool schemas without rewriting the entire prompt universe. You can swap memory strategies or retrieval methods while keeping the top-level interaction stable.

That is a major architectural gain.

There is also a philosophical gain. It frees us from the false binary between “talking naturally” and “going back to code.” We are not simply bouncing between total informality and total formalism. We are building multi-layer systems where different degrees of formality belong in different places.

The human should not be forced to express every intention in rigid syntax. The machine should not be forced to carry every internal coordination step in human prose.

The protocol stack allows both truths at once.

Layering Solves Problems and Creates New Ones

Of course, the problems arrive immediately.

Layering creates opacity. Once more control happens below the visible prompt, users may lose sight of what is actually governing behavior. Hidden system prompts, invisible retrieval, latent memory shaping, and inter-agent subprotocols can make the system powerful and less inspectable. Anyone serious about AI governance should worry about that, and not in a performative way.

But that worry is not an argument against the stack. It is evidence that the stack is real.

No one worries about invisible layers in a system that does not have them.

In that sense, we are already past the era of naive prompting. The visible chat box survives, but it is increasingly the polite fiction that hides a much larger control apparatus.

And that may be healthy. Computing has always needed boundary surfaces that are easier than the machinery beneath them. The mistake is only to confuse the surface with the whole machine, which is exactly what a lot of current discourse keeps doing.

So are we still dealing with prompting?

Yes, if by prompting we mean the top-level act of expressing intent to a language-shaped system.

No, if by prompting we mean the full control problem.

That full problem now belongs to protocol design, context architecture, tool governance, memory management, and eventually machine-native coordination.

The prompt is not disappearing. It is being demoted from sovereign command to one layer in a growing stack, which is probably healthier for everyone except people who enjoyed pretending the prompt was the whole art.

And that, in my view, is the beginning of a more mature understanding of what these systems really are.

Summary

What we casually call prompting is already splitting into layers: human intent, behavioral framing, operational context, tool control, memory management, and machine coordination. Natural language remains crucial, but it no longer has to carry every control concern by itself. As systems mature, the visible prompt becomes less like a sovereign instruction and more like the top layer of a broader protocol architecture.

That shift is not a loss of humanity. It is an increase in architectural honesty. The system is finally being described in the shape it actually has, rather than the shape the chat UI flatters us into seeing.

Once we accept that the prompt is only the top layer of the stack, what should remain visible to the human user and what should never be hidden underneath?

Security Findings as Design Feedback

Sun, 22 Feb 2026 00:00:00 +0000

Security reports are often treated as defect inventories: patch issue, close ticket, move on. That workflow is necessary, but it is incomplete. Many findings are not isolated mistakes; they are design feedback about how a system creates, hides, or amplifies risk. Teams that only chase individual fixes improve slowly. Teams that read findings as architecture signals improve compoundingly.

A useful reframing is to ask, for each vulnerability: what design decision made this class of bug easy to introduce and hard to detect? The answer is frequently broader than the code diff. Weak trust boundaries, inconsistent authorization checks, ambiguous ownership of validation, and hidden data flows are structural causes. Fixing one endpoint without changing those structures guarantees recurrence.

Take broken access control patterns. A typical report may show one API endpoint missing a tenant check. The immediate patch adds the check. The design feedback, however, is that authorization is optional at call sites. The durable response is to move authorization into mandatory middleware or typed service contracts so bypassing it becomes difficult by construction. Good security design reduces optionality.

Input-validation findings show similar dynamics. If every handler parses raw request bodies independently, validation drift is inevitable. One team sanitizes aggressively, another copies old logic, a third misses edge cases under deadline pressure. The root issue is distributed policy. Consolidated schemas, shared parsers, and fail-closed defaults turn ad-hoc validation into predictable infrastructure.

Injection flaws often reveal boundary confusion rather than purely “bad escaping.” When query construction crosses multiple abstraction layers with mixed assumptions, responsibility blurs and dangerous concatenation appears. The design-level fix is not a lint rule alone. It is to constrain query creation to safe primitives and enforce typed interfaces that make unsafe composition visibly abnormal.

Security findings also expose observability gaps. If exploitation attempts succeed silently or are detected only through external reports, the system lacks meaningful security telemetry. A mature response adds event streams for auth decisions, suspicious parameter patterns, and integrity checks, with dashboards tied to operational ownership. Detection is a design feature, not a post-incident add-on.

Another pattern is privilege creep in internal services. A report might flag one misuse of a high-privilege token. The deeper signal is that privilege scopes are too broad and rotation or delegation models are weak. Architecture should prefer least-privilege tokens per task, short lifetimes, and explicit trust contracts between services. Otherwise the blast radius of ordinary mistakes remains unacceptable.

Process design matters as much as runtime design. Findings discovered repeatedly in similar areas indicate review pathways that miss systemic risks. Security review should include “class analysis”: when one issue appears, search for siblings by pattern and subsystem. This turns isolated remediation into proactive hardening. Without class analysis, teams play vulnerability whack-a-mole forever.

Prioritization also benefits from design thinking. Severity alone does not capture strategic value. A medium issue that reveals a widespread anti-pattern may deserve higher priority than a high-severity edge case with narrow reach. Decision frameworks should account for recurrence potential and architectural leverage, not just immediate exploitability metrics.

Communication style influences whether findings drive design changes. Reports framed as blame trigger defensive behavior and minimal patches. Reports framed as system learning opportunities invite ownership and broader fixes. Precision still matters, but tone can determine whether teams engage deeply or optimize for closure speed.

One practical method is a “finding-to-principle” review after each security cycle:

Summarize the concrete issue.
Identify the enabling design condition.
Define a preventive principle.
Encode the principle in tooling, APIs, or architecture.
Track recurrence as an outcome metric.

This process converts incidents into institutional memory.

Security maturity is not a state where no bugs exist. It is a state where each bug teaches the system to fail less in the future. That requires treating findings as feedback loops into design, not just repair queues for implementation. The difference between those mindsets determines whether risk decays or accumulates.

In short: fix the bug, yes. But always ask what the bug is trying to teach your architecture. That question is where long-term resilience starts.

Teams that institutionalize this mindset stop treating security as a parallel bureaucracy and start treating it as part of system design quality. Over time, this reduces not only exploit risk but also operational surprises, because clearer boundaries and explicit trust rules improve reliability for everyone, not just security reviewers.

Finding-to-principle template

Finding: <concrete vulnerability>
Class: <auth / validation / injection / secrets / ...>
Enabling design condition: <what made this class likely>
Preventive principle: <design rule to encode>
Enforcement point: <middleware / schema / API contract / CI check>
Owner + deadline: <who and by when>
Recurrence metric: <how we detect class-level improvement>

This keeps remediation focused on recurrence reduction, not ticket closure optics.

Turbo Pascal Units as Architecture, Not Just Reuse

Sun, 22 Feb 2026 00:00:00 +0000

Most people first meet Turbo Pascal units as “how to avoid copy-pasting procedures.” That is true and incomplete. In real projects, units are architecture boundaries. They define what the rest of the system is allowed to know, hide what can change, and make refactoring survivable under pressure.

In constrained DOS projects, this was not academic design purity. It was the difference between shipping and debugging forever.

Interface section is a contract surface

A good unit interface exposes minimal, stable operations. It does not leak storage details, timing internals, or helper routines with unclear ownership. You can read the interface as a capability map.

unit RenderCore;

interface
procedure BeginFrame;
procedure DrawSprite(X, Y, Id: Integer);
procedure EndFrame;

implementation
{ internal page selection, clipping, palette handling }
end.

Notice what is missing: page indices, raw VGA register details, sprite memory layout. Those remain private so callers cannot create illegal states casually.

Separation patterns that work

A practical retro project often benefits from explicit layers:

SysCfg: startup profile, paths, feature flags
Input: keyboard state and edge detection
RenderCore: page lifecycle and primitives
World: simulation and collision
UiHud: overlays independent of camera

Each layer exports what the next layer needs, and no more.

This is still modern architecture wisdom, just with smaller tools.

Compile-time feedback as architecture feedback

One advantage of strong unit boundaries: breakage appears quickly at compile time. If you change a function signature in one interface, all dependent call sites surface immediately. That pressure encourages deliberate changes rather than implicit behavior drift.

When architecture boundaries are vague, breakage tends to become runtime surprises. In DOS-era loops, compile-time certainty was a strategic advantage.

State ownership rules

Global variables are tempting in small projects. They also erase accountability. Better pattern:

each unit owns its state
mutation happens through explicit procedures
read-only queries are exposed as functions

unit FrameClock;

interface
procedure Tick;
function FrameCount: LongInt;

implementation
var
  GFrameCount: LongInt;

procedure Tick;
begin
  Inc(GFrameCount);
end;

function FrameCount: LongInt;
begin
  FrameCount := GFrameCount;
end;
end.

This small discipline scales surprisingly far.

Circular dependencies are architecture warnings

If Unit A needs Unit B and B needs A, the system is signaling a design issue. In Turbo Pascal this becomes obvious quickly because cycles are painful. Use that pain as feedback:

extract shared abstractions into Unit C
invert direction of calls through callback interfaces
move policy decisions up a layer

The language/tooling friction nudges you toward cleaner dependency graphs.

Testing mindset without modern frameworks

Even without a test framework, you can create deterministic validation by small harness units:

fixture setup procedure
operation call
assertion-like result check
text output summary

The key is isolating seams through interfaces. If a rendering unit can be called with prepared buffers and predictable state, manual regression checks become cheap and reliable.

Architecture and performance are not enemies

Some developers fear unit boundaries will cost speed. In most DOS-scale projects, the bigger performance wins come from algorithm choice and memory locality, not from collapsing all code into one monolith. Clear units help you identify hot paths accurately and optimize where it matters.

For example, keeping low-level pixel paths inside RenderCore makes targeted optimization straightforward while preserving clean call sites elsewhere.

Cross references in this project

These articles show the same pattern from different angles:

Different domains, same operational truth: explicit boundaries reduce failure ambiguity.

A migration strategy for messy codebases

If you already have a tangled Pascal codebase, do not rewrite everything. Do staged extraction:

identify one unstable subsystem
define minimal interface for it
move internals behind unit boundary
replace direct global access with explicit calls
repeat for next subsystem

This approach keeps software running while architecture improves incrementally.

Turbo Pascal units are sometimes framed as nostalgic language features. They are better understood as practical architecture tools with excellent signal-to-noise ratio. Under constraints, that ratio is everything.