On 12 October my Mac choked. Several coding agents were working on Krizaka at the same time, each with its builds, its containers and its simulator, and the system ended up refusing to open one more file. I tell the story in the post about the Mac. That day I understood something simple: letting agents write code isn't magic. It's organisation.
Two words are everywhere right now: "agentic" and "agnostic". I take them one at a time here, simply, with what we really built, and what is still in progress.
What makes a system agentic
A model on its own answers a question. A system becomes agentic when you give it five things.
A goal, rather than a question: "summarise the new PDFs in this folder every morning". Tools, to act on the world: read a file, query a database, call an API (I explain tools and MCP in the basics). Memory, to know where it stands. A loop: plan, act, look at the result, go again. And a human approval before anything that has a real effect.
The fifth one is what separates an agent from an intern left alone with the keys.
Agnostic: what it buys, what it costs
"Agnostic", here, means the system doesn't depend on one model or one provider. In Orazaka, the engine I'm building, the model in use is a row in a database: a table links each model name to its provider, and a router reads those rows on every call (ADR-030). A local model on Ollama and a hosted model go through the same API.
What it buys is concrete. No lock-in with a provider. The right to pick the cheapest model that's good enough, task by task. And sovereignty: the same work can run on a machine you control.
What it costs is said less often. You aim at the lowest common denominator: a feature specific to one provider is useless if the others don't have it. You have to evaluate each model on your own tasks, because a model name guarantees no quality. And there are traps, like the step that silently went to another model than the one asked for. Since then, a model whose provider doesn't answer fails and says so.
Workflows whose steps are data
A free agent decides its own steps. For customers, I made a more careful choice. A Studio, in Orazaka, is a workflow: a versioned graph of steps (model calls, transforms, human approvals, connectors), described as data. A pack is a folder that ships Studios; installing it writes rows in a database and changes no code (the packs documentation).
Prompt transformation is one of those steps. What the person types is wrapped in a structured direction before it reaches the model: the subject first, then the light, the lens, the palette, and the exclusions moved into the text when the model doesn't read a negative prompt. I measured what that changes in the anatomy of a prompt.
And before any step, the content policy acts as a guardrail: the request is classified locally, and what the operator refuses goes nowhere. I talk about it in the post on models that refuse.
Local agents: in progress
The real agent, the one that works on your machine while you sleep, is in progress. The architecture is written in a decision that isn't merged yet (ADR-079), and the first slice, a summary of new PDFs every morning on the Mac, is in review.
What it plans is more interesting to me than any demo. Every tool declares its effect: read, write, external, exec, and an unknown effect is treated as exec. Nothing writes or goes out without approval. An "always allow" becomes a narrow, recorded grant. There are budgets per run and per day, a kill switch, an audit log where each entry is chained to the previous one, and no shell in the first version. In the first slice the plan is fixed: the model doesn't even choose its tools. And everything must be able to run offline.
I write it in the future tense because it isn't shipped. I'll come back when it runs.
How I got out of vibe coding
Vibe coding is asking an AI to write code, checking that it seems to work, and moving on. At first it's exhilarating. Then the Mac chokes, one session breaks what another did, and nobody knows who changed what.
Krizaka is largely written by agent sessions that I direct, often several in parallel. What changed isn't the agents, it's the guardrails around them.
A rules file every session reads before starting: a failing test first, then the fix; never merge while a check is red or pending; one small pull request per step. A lock for heavy tasks, added on 12 October. A CI that refuses what doesn't pass. And rules written after each mistake: a merge done too early, before a security scan finished, gave the rule "never merge with a pending check"; a session that printed a secret in its output gave an automatic guard that refuses any command able to do it.
What I take from it: an agent doesn't become reliable because it's intelligent. It becomes reliable because you give it a clear goal, limited tools, tests that say no, and a person who approves what matters.
What you can take from it
If someone sells you an "agentic" system, ask for its five pieces: the goal, the tools, the memory, the loop, and above all the human approval. If someone sells you an "agnostic" system, ask how it evaluates the models it offers you. And if you let agents write your code, write the rules they'll have to follow first, then the tests that will make them fail.
