If you’ve followed me for any time at all, you know by now one of my favorite things to ask is, “What actually is an LLM, anyway?”

Not the hype version, but what you really get once you strip away the marketing, the endless discussions about machines that think, and the amusingly convincing chatbots (or the industry’s insistence that they’re the only thing we can build with an LLM). When we do all that, then what are we actually working with?

A processor.

More specifically, a processor of communication. Text, images, audio, and other forms of information that carry meaning. In other words, signs.

Which means that, unlike conventional processors, where instructions, inputs, and operations are carefully defined, a language model can receive all three wrapped up in one singular, messy blob of human communication.

That’s a miraculous capability. One that was borderline impossible just a few years ago, but that we can now experiment with on ordinary consumer hardware.

Except it also introduces an enormous problem.

Just because something can be represented in language doesn’t mean a language model should be responsible for doing it.

We can describe mathematics, databases, software, physical systems, and nearly anything else through communication. That doesn’t make describing those processes equivalent to executing them. And it certainly doesn’t mean that emulating executing of them with language is efficient (or reliable).

We’ve already spent decades learning how to make computers do those things reliably. We’ve got tools for that.

So what happens if we stop asking language models to emulate the entire computer and start treating them as a new kind of computing component?

That’s what drives semiotic processing, a novel, powerful, and performant way to leverage LLMs without all the headaches we’ve become accustomed to from ordinary LLM-first engineering that results in AI and agent applications.

It’s the approach I use in my own work as well: I treat an LLM as a processor for interpreting and transforming representations of meaning, and build the surrounding system using established software engineering principles. That’s what powers SkillSaige. While it draws on RISC architecture principles and the growing practice of compound AI systems, semiotic processing asks a more specific question: what should the language model process, and what must the surrounding system remain responsible for? Essentially, it turns the whole problem on its head.

And you can do it too, and start to unlock the benefits right now. There are five principles that guide it.

1. It’s a Processor. Treat It Like One.

When we think we’re interacting with an expert, even an imperfect one, we unconsciously leave things unsaid. We expect it to understand our intent, infer missing information, and recognize our assumptions.

Then we get frustrated when it doesn’t.

But when we approach it as a processor, we start asking different questions about our work.

Did I provide the necessary information? Is the operation clearly defined? What gaps am I asking the model to fill without guidance?

A language model can produce a plausible interpretation of what we intended without that interpretation being correct.

Which is part of what I call the meaning gap: the distinction between manipulating representations of meaning to communicate something and the real-world, tangible, rigid truth of what those meanings are trying to represent.

Thinking in terms of processing gives us a more useful way to investigate failures. We can examine the inputs, assumptions, and operations instead of arguing with a simulated expert.

2. Use It Where Meaning Matters.

In plain English: stop making the language processor do math.

Seriously. Why ask a language model to emulate arithmetic when the computer running it already has a perfectly good calculator? Why did it take so long to start having chatbots call math programs? That’s not a breakthrough, that’s basic engineering.

But the same applies to databases, formal logic, authoritative records, and anything else we already have reliable computational methods for handling.

A semiotic processor is useful where interpreting or transforming meaning is intrinsic to the task. Which includes extraction, classification, comparison, reformulation, synthesis, subjective evaluation, and constrained generation. But that’s not the same as giving an agent a tool: because the decision to invoke a tool is part of using the tool itself. If you’re letting the model do that, you’re letting it reconstruct the heuristics you should have defined for when a tool is necessary. That’s not meaning, that’s math and engineering.

Imagine processing a messy invoice. A model could interpret the document and extract line items into a structured format. But ordinary software can then validate those entries, calculate totals, and update the appropriate records. No agent, no AI, no tools needed (and none of the costs involved with that either).

Each component does the work it’s suited for.

The model is extremely useful here, make no mistake. But we don’t need it to pretend to be an accountant, calculator, database, and accounting application all at once.

3. Bound It. Verify It.

This principle has two parts.

3a. Bound the operation

Make each model operation as small and clearly defined as practical.

Think about clicking Save in a word processor. That single action involves numerous operations across the application, operating system, file system, and hardware. But the processor isn’t deciding what Save means or inventing the steps required to accomplish it each time. The surrounding software orchestrates those operations deterministically. So imagine if clicking Save simply sent the words “save my document” to a language model and expected it to figure everything else out.

What should be saved? Where? In what format? Should it overwrite anything? How does it know whether the operation succeeded? That’s uncomfortably close to what we’re asking an LLM to do when we hand it a massive task and expect it to carry the entire thing through independently.

Every inferred intermediate step introduces another chance for error. Worse, later steps may depend on earlier mistakes. And that doesn’t even factor in the wasted cost of making it “re-solve” the exact steps every time its invoked.

So instead, break complex tasks into explicit steps with defined inputs, outputs, and constraints. Before you even touch the LLM.

3b. Verify independently

Don’t ask a model to generate something and treat its eloquent assurance that the result is correct as verification.

Wherever possible, validate results independently instead. Use parsers for syntax, schemas for structure, arithmetic for calculations, and authoritative sources for external facts. The model doesn’t need to invoke that, the computer can.

And for subjective questions, a separate semiotic operation can be quite useful. Evaluating an existing result against a defined rubric, for example, allows generation and evaluation to be examined separately. But always do it seperately.

The important distinction is that producing a result and checking that result are separate operations. Always. Ideally on their own context threads if you’re still using those.

This applies whether you’re building software or simply using a chatbot.

4. Context Is Input.

Everything you provide to a language model can affect its output. Everything.

Your instructions, examples, previous exchanges, background information, wording, and even the style of your communication are all part of the material being processed. And with commercial chatbots, there’s often substantial additional context you never see: system instructions, tool definitions, behavioral requirements, and other material provided by the application.

All of it can influence the result.

That’s one reason two people can ask essentially the same question and receive substantially different responses. But it’s also why arguing with your chatbot get’s you nothing but dramatically polluted compute context in the end (and why they can be jailbroken so easily without non-LLM safeguards in place).

So be deliberate with context.

Provide the information necessary for the operation. Keep unrelated material out where possible. Make instructions and output expectations explicit. And if you find yourself adding pages of behavioral instructions just to make a seemingly simple task work reliably, consider whether you’ve maybe collapsed several operations together.

One of the longer-term opportunities here is to translate wildly different human requests into stable, inspectable operations that software can execute consistently. Which has huge implications for reliability, accessibility, and how much a user’s phrasing determines the quality of the tools available to them. It shouldn’t, but right now it often does.

5. Keep the System in Charge.

This is where everything comes together.

5a. Keep state external

The model should not be responsible for maintaining your application’s authoritative state.

Persistent facts, permissions, workflow steps, completed actions, constraints, and other critical information should live in systems designed to manage them.

The model can interpret that information and work with it, but the surrounding software should maintain the actual records.

5b. Keep authority external

Likewise, the model shouldn’t be the final authority over what the system does.

It can interpret an instruction, propose an action, or transform a request into a structured command.

But the surrounding software should determine whether that command is valid, permitted, and appropriate to execute through debuggable, deterministic rules.

Imagine someone saying, “Move my appointment to next Thursday afternoon.” A semiotic processor can interpret that request and propose a structured action. The calendar system can check which appointment, available times, permissions, and conflicts before making a change. Reliable results, every time, and no accidental triple booking (if you designed your calendar system well, at least).

And if you’re simply using ChatGPT or another chatbot for your own work?

You’re the surrounding system.

Keep your authoritative records in appropriate tools, verify important results, and retain responsibility for decisions and actions.

So What Does This Actually Change?

Put these principles together and you arrive at one general architectural rule:

Do not ask a semiotic processor to simulate a system that can be represented explicitly.

The specific model you’re using becomes less important. Within reason, of course. Models differ substantially in their capabilities, accuracy, capacity, and efficiency. Some operations genuinely require much more powerful models than others. But that’s true of ordinary CPUs, too.

With this approach, once you’ve defined the operations your application needs, you can evaluate models against those requirements and trust that you have the measurements you need. No more guessing.

You can use smaller models for simpler operations, larger ones where necessary, and replace one with another when it makes sense. More importantly, you can test those components independently. Run some locally and others remotely. Measure their performance and costs without rebuilding your application around the quirks of a particular model.

In my own work on SkillSaige, this approach has already produced incredible practical improvements.

Moving from a largely model-driven conversational system to an explicitly orchestrated architecture reduced token consumption from roughly 98,000 to 6,700 per training scene, while allowing most model operations to run on models with fewer than five billion parameters. And it unlocked behavior that was previously exceptionally difficult to achieve with a pure-LLM approach, making it safe, debuggable, and reliable for training people. Which is what really matters.

Those are application-specific results, of course. We’ve had an excellent team able to apply these principles in SkillSaige. But the results demonstrate what becomes possible when we stop using model capacity to compensate for missing software architecture.

We don’t need to wait for the next enormous model, or for a handful of companies to decide what computing with this technology should look like.

Open-weight models, affordable local hardware, and ordinary software engineering already give us the tools to start building useful systems that aren’t permanently dependent on a particular model or vendor.

Better models will continue to be valuable. So will better hardware. But those are components of a much larger computing ecosystem.

The processor is the new part.

The rest of the computer? We already know how to build it.