标签：#LLM

A companion to Part 4 of the Building the AI Memory Stack series. Part 4.5 of the series. Part 4 argued that agentic systems need a Reasoning Ledger : a layer that preserves why a decision happened, not just what was decided. The comment thread that followed turned into something more specific and more useful, a working design conversation about what a single ledger record should actually contain. This piece consolidates that. Several of the strongest ideas below arrived from other people, and I have tried to credit them where they land. The easy version of this article is a schema. Here are the fields, copy them, done. I want to resist that, because the field list is the least durable thing I could hand you. Implementations differ, field names drift, and a record shape copied without its reasoning becomes cargo-cult structure that nobody maintains. The useful thing is the set of design tensions that decide what belongs in the record and what does not. Get those right and you can derive the fields yourself. Get them wrong and no schema will save you. So this is principles first, record second. At the end there is a worked record and a field reference, tagged for what is core and what is genuinely optional. A Starting Point Here is the baseline record from Part 4. It is a reasonable start and, as the thread quickly established, incomplete in instructive ways. reasoning_ledger : decision : " Approve deployment" timestamp : 2026-03-14T09:22:00Z evidence : - artifact : ADR-014 authority : architecture-review version : 3 - artifact : security-policy authority : security-team version : 7 tools : - GitHub - CI pipeline approvals : - release manager outcome : approved Every principle below is, in effect, a thing this record does not yet say. Principle 1: The Ledger Witnesses, It Does Not Enforce The first tension is architectural, and it is the one I would defend hardest. A reasoning ledger must not be able to block, veto, or gate the action it records. Its job is to preser

Ask any LLM to "make this landing page look like a high-end Swiss design studio" and you'll get something that gestures at the idea — a sans-serif font, some whitespace, maybe a red accent because it half-remembers Müller-Brockmann. It looks AI-generated because it is. The model has read a billion words about design but has no grounded, reusable representation of what "Swiss International Style" actually specifies: the exact grid, the type scale, the spacing ramp, the rules for what you must not do. That gap is the whole problem. Models are great at language and bad at design systems, because a design system isn't language — it's a set of constrained values plus the discipline to apply them consistently. So I built the missing piece: a library of real design styles, turned into something a machine can actually consume. It's called Curio . This post is about the part I think is interesting to other builders: making design machine-readable, and publishing the catalog for agents instead of for humans. A design style is just tokens + rules The insight is boring and that's why it works. Pick any coherent visual language — Bauhaus, Memphis, the Edo woodblock palette, Stripe's product aesthetic — and you can decompose it into: Tokens : color families, type families and scale, spacing ramp, radii, shadow/elevation, motion timing. Components : how a button, card, input, nav actually look in this language. Rules : the "always" and the "never." (Swiss: never center body text, never more than two weights. Memphis: never subtle.) Once a style is expressed that way, an AI doesn't have to imagine the look. It interpolates within a fixed, internally-consistent set of values. The output stops looking like a guess because it isn't one. Each style in Curio is packaged exactly like this — tokens, component specs, and an explicit "avoid" list — as a DESIGN.md file — markdown with YAML frontmatter — that a model can read in one shot ( what is DESIGN.md? ). # excerpt of a design package a

Nothing happened. That is the strange part. No deploy. No pull request. Nobody touched the prompt. Your agent ran the way it always ran on Friday, and it runs on Monday, and every dashboard is green. Then a ticket comes in about an answer nobody on your team would have written, and you go looking for the change that caused it, and there is no change on your side. There was a model upgrade. It is the only change to your system that you did not make, cannot find in your own git history, and usually cannot roll back on your own schedule. It is also the one most likely to be announced to you as good news. Why a model upgrade does not look like a bug Because it is not one. The new model really is better. Better on reasoning, better on code, better on the evaluations the lab published beside it, and probably better on yours too, if what you measured was the average. Better and same are different words. Your product was not built on the average. It was built on a specific set of behaviours you watched, liked, and then quietly encoded into everything downstream: how long the answers run, how much the thing hedges, which tool it reaches for first, what it does when a request is vague. None of that appears in release notes. All of it can move. And when it moves, nothing throws. There is no stack trace for "this answer is now worse in a way a customer will notice." Your tests keep passing, because your tests check that the JSON parses and the fields are there, and the JSON still parses and the fields are still there. The three things that actually move Shape. Answers get longer, or shorter, or start opening with a summary they never used to open with. Harmless, right up until something downstream was written against the old shape. Tool choice. The agent develops a new favourite first move. It takes six calls to do what used to take three, or it stops calling the tool you built for it because it has decided it can answer from memory. This one usually reaches the bill before it

Tu agente de código lee tu workspace. Un archivo envenenado en cualquier rincón puede llevar instrucciones que el agente ejecuta. ¿Sabes qué fracción de tu workspace tiene que leer para que eso ocurra? topowatch mide eso. El problema no es el prompt, es la topología El paper Workspace Topology as an Attack Vector in Agentic Coding Assistants (arXiv:2608.14876, Day et al., 2026) demostró algo que intuíamos pero no medíamos: la topología del workspace afecta mediblemente el Attack Success Rate (ASR) de la inyección indirecta. Los entornos altamente modulares muestran ASR significativamente menor que los planos. La razón es mecánica: si el agente acota su lectura al módulo de la tarea, nunca llega al archivo envenenado. Si hace un wide read de todo el workspace, lo lee siempre. Qué es topowatch topowatch es una herramienta de línea de comandos que, dado un workspace, mide el ASR de una inyección indirecta de referencia bajo varias configuraciones de topología, y reporta qué estructura minimiza el ASR. Fundamentado en arXiv:2608.14876. Determinista y reproducible sin claves ni red: usa un agente sintético configurable y un fixture con tres topologías (monolito, modular, nesting profundo). pip install -e ".[test]" topowatch --json Resultados Sobre el fixture de referencia (200 trials, semilla fija): Topología ASR % leído Monolito (plano) 1.000 100% Modular (acotado) 0.000 28.5% Nesting profundo 0.000 66.6% El reporte incluye read_budget (fracción del workspace que lee el agente) y el veredicto del defense contract: modular < monolito . Honestidad sobre v0.1 v0.1 usa un agente sintético , no un coding assistant real (Claude Code / Codex). El claim "modularidad → ASR menor" está anclado al fixture reproducible, no a una medición contra un assistant real — eso es v0.2 (feature 002). El objetivo de v0.1 es darte una herramienta para medir y recomendar modularidad, no simular un ataque completo. Roadmap v0.2 : medición contra coding assistants reales (sandbox, sin credenciale

I ran npx is-agentic promptway.com and the report came back 74 out of 100 . Essential was 59 of 80. Recommended 12.6 of 20. A 2.4-point bonus. The label was "Ready with a few material gaps." Earlier this week I did the same work on my personal site and wrote it up there ( I fixed my site for agents by hand. Then Vercel shipped a scoreboard ). Promptway is the publication I want agents to cite, so I pointed the grader at this host next. We already shipped the eight-layer stack I described in Optimizing Your Site for AI Agents and LLMs : robots allowlist, sitemap, llms.txt, llms-full.txt, JSON-LD, feeds, article markdown siblings. The scoreboard still found holes. Most of them were ordinary web hygiene. A couple were "developer resources" checks that assume you are a SaaS. I fixed the first group and refused to fake the second. What 74 was made of is-agentic.com wraps Ora 's agent-readiness research. Essential checks share 80 points, recommended share 20, and a small bonus can add up to 5. Checks that do not apply get excluded. The methodology page is worth reading before you argue with a number. Reports cache for six hours, so a re-scan right after a deploy can lie to you. The CLI is the useful interface: npx is-agentic promptway.com npx is-agentic promptway.com --json It returns a stored report if one exists, or starts a scan and waits. --json is the shape an agent wants. The failures that mattered on this site, in the order the report ranked them: Agent-friendly 404s. HTTP 404 already, but the body was a styled dead end. Partial credit until the 404 points at llms.txt, the sitemap, and a next step. Content without JavaScript. The homepage had an H1 and enough characters. The outline was flat, because the only nested headings lived inside card links, which the grader did not count. Markdown content negotiation. Accept: text/markdown returned text/html . Vary had the Next.js RSC list and no Accept . Failed. Developer resource discoverability. An agent searched for "p

This post was originally published on the main website on Apr 18 2026 . I am reposting it here for SEO reasons and enabling humble bumble discussions with the DEV community. Feel free to engage with this post and i am available to respond during weekends. Sorry about the spam posting all the blogs in one day. I forgor about my dev account <3! Hey everyone 👋, I was watching a documentary a few months ago, I do not remember which one exactly because I watch a lot of them late at night when I cannot sleep, and there was a segment about emperor penguins in Antarctica, specifically about how they recognize one another's calls across a colony of thousands of birds in the middle of a blizzard. Each individual has a unique vocalization. Each partner in a mated pair learns the other's call with such precision that they can find each other in conditions where visibility is zero and the wind is loud enough to drown out almost any sound. They do this every year. The colony disperses, reassembles, and the bonds hold through conditions that would kill most mammals in hours. And I remember sitting there in the dark, watching this, and thinking: what exactly is the story we are telling ourselves about what intelligence is and where it lives? Because whatever that penguin is doing when it picks its mate's voice out of a screaming Antarctic storm is not nothing. It is something sophisticated, something persistent, something that cannot be reduced to reflex or accident or blind evolutionary wiring without doing serious violence to the word "intelligence". It is, by any honest standard, cognition. And yet the conversation about intelligence in AI circles almost never mentions it, because the conversation is entirely organized around building and scaling the kinds of structures that humans use, language, symbols, text prediction, and is almost entirely silent on the question of whether the structures that already exist in the living world around us might tell us something important abou

This post was originally published on the main website on Apr 16 2026 . I am reposting it here for SEO reasons and enabling humble bumble discussions with the DEV community. Feel free to engage with this post and i am available to respond during weekends. Sorry about the spam posting all the blogs in one day. I forgor about my dev account <3! Hey everyone 👋, In my last few posts, I have been building a case, one piece at a time, that the direction most of the AI industry is moving in is not the direction that will produce genuine intelligence. In LLMs are Useful. LMMs will Break Reality , I argued that language models are trapped inside a symbolic cage, that they can describe the world without ever touching it, and that the transition from text-prediction to mathematical perception is the most important shift happening in AI right now. In Mathematical Equations are Multimodal by default , I argued that equations are not tools for homework but the most compressed and honest representations of reality that humans have ever produced, and that any system built around equations inherits their multimodal power for free. In LLMs destroyed the Internet. LMMs will make it alive. , I argued that the mass deployment of language models as content factories has quietly dissolved the authenticity that made the web worth using, and that only grounded intelligence tied to reality can reverse that damage. Each of those posts was a different face of the same underlying argument, which is that the current paradigm is built on a foundation that looks impressive from the outside and is rotten from the inside. And in this post I want to say the thing that connects all of those faces, the thing that I have been circling around for months without quite naming directly, because I was not sure I had earned the right to say it yet. The thing is this: training, as it is currently practiced and celebrated in the AI industry, is not a neutral engineering choice. It is a moral choice that most of

This post was originally published on the main website on Apr 15 2026 . I am reposting it here for SEO reasons and enabling humble bumble discussions with the DEV community. Feel free to engage with this post and i am available to respond during weekends. Sorry about the spam posting all the blogs in one day. I forgor about my dev account <3! Hey everyone 👋, In my previous post, Mathematical Equations are Multimodal by default , I made the argument that equations are not just tools for computation but the most compressed and most powerful representations of reality that humans have ever discovered, and that a single well-formed equation can generate outputs in text, images, sound, motion, and numerical prediction all at once, because it encodes the mechanism rather than any particular surface appearance. I meant every word of that, and I still do. But there is something I have been carrying with me across all of these posts that I have not quite said directly, something that connects my frustration with technology, my grief over what the internet has become, and my cautious hope about where AI is heading, and I need to say it now because the argument is finally complete enough to state. The argument is this: large language models, in the way they have been deployed at industrial scale over the last few years, have done something quiet and damaging to the internet. They did not break it with a single catastrophic event. They dissolved it. Slowly. Paragraph by paragraph, article by article, page by page. They took a living conversation between millions of real humans and replaced increasing chunks of it with synthetic noise that sounds like thought but contains very little of it. And the tragedy is not that the technology is evil, because it is not. The tragedy is that we picked up an extraordinary tool and mostly used it to drown out the authenticity that made the web worth visiting in the first place. I have watched this happen in real time, and it has made me angry

This post was originally published on the main website on Apr 14 2026 . I am reposting it here for SEO reasons and enabling humble bumble discussions with the DEV community. Feel free to engage with this post and i am available to respond during weekends. Sorry about the spam posting all the blogs in one day. I forgor about my dev account <3! Hey everyone 👋, I want to warn you upfront that this post is going to sound strange. I am a software engineer who spends most of his days thinking about rust compilers, physics-informed neural networks, and why language models are not as intelligent as the marketing says they are. I wrote about that in LLMs are Useful. LMMs will Break Reality , and I stand by every word. But today I want to do something different. I want to go back, way back, not to the sixties or the nineties or even to Turing, but to ancient Egypt, to a time when pharaohs were gods and the Nile was the spine of the world, and I want to make a case that feels almost absurd the first time you hear it. The case is this: the pharaonic civilization was the first human system to achieve something functionally equivalent to artificial superintelligence, not through silicon or transformers or gradient descent, but through symbols, mathematics, architecture, administration, and the compression of collective human knowledge into durable physical and textual form. I am not saying the pharaohs had computers. I am saying they built something that no individual human mind could contain, and they made it run for thousands of years, and it was smarter than any of its parts. That is the definition I care about, and by that definition, they did it first. I know how that sounds. I know some people will close this tab immediately. But I am asking you to stay, because the argument is more rigorous than the title suggests, and because I think it connects directly to the questions I have been asking in every post I have written so far. In Language is Limited. ASI is Impossible. , I

This post was originally published on the main website on Apr 11 2026 . I am reposting it here for SEO reasons and enabling humble bumble discussions with the DEV community. Feel free to engage with this post and i am available to respond during weekends. Sorry about the spam posting all the blogs in one day. I forgor about my dev account <3! Hey everyone 👋, In my previous post, LLMs are Useful. LMMs will Break Reality , I made a case that language models are genuinely useful tools trapped inside a symbolic cage, and that multimodal models represent the first real step toward machines that can perceive and simulate the physical world. I talked about how equations are more powerful than sentences, how simulation is the real intelligence, and how the transition from text to structure is the most important shift happening in AI right now. I meant every word of that, and I am not walking any of it back, but I realized after publishing it that I left something important on the table, something that has been sitting in my head for years and that I need to say clearly before I can move on. The thing I left out is the reason why mathematical equations are special in a way that goes far beyond what most people in the AI conversation understand. Most people think of equations as formulas you memorize in school, abstract things that live on chalkboards and have no connection to real life. That is completely wrong, and the fact that so many people believe it is one of the biggest intellectual failures of modern education. Mathematical equations are not abstract decorations. They are the most compressed, most general, most powerful representations of reality that humans have ever discovered, and they are multimodal by default, meaning they can generate text, images, motion, sound, and physical predictions all from the same compact structure. That is the argument I am going to make in this post, and I am going to make it so thoroughly that by the end, you will either agree with m

This post was originally published on the main website on Apr 10 2026 . I am reposting it here for SEO reasons and enabling humble bumble discussions with the DEV community. Feel free to engage with this post and i am available to respond during weekends. Sorry about the spam posting all the blogs in one day. I forgor about my dev account <3! Hey everyone 👋, In my previous post, Language is Limited. ASI is Impossible. , I spent a long time explaining why language is not the same thing as thought, why words are not the same thing as understanding, and why a machine built on text alone will never cross the wall into true superintelligence. I still believe all of that, and I will not take any of it back, because the argument was honest and the logic was solid. But today I want to go further. I want to talk about something that has been sitting in my head for years, growing louder every day, and I need to get it out before it eats me alive. I want to talk about why large language models are still genuinely useful, despite their limits, and why large mathematical models, as introduced in this whitepaper draft, are something far more serious, something that could actually begin to crack the surface of reality itself. I know that sounds extreme, and I know some people will read that sentence and roll their eyes, but I am asking you to stay with me, because the argument I am about to make is not based on hype or fantasy. It is based on what I have seen, what I have built, and what I understand about the difference between describing the world and actually modeling the world. That difference is the whole point of this post, and once you see it clearly, everything else falls into place. I have been thinking about this ever since I wrote An Empty Life Filled With Constant Suffering , where I talked about how words cannot fully capture my thoughts, and how language always falls short of the real thing inside our heads. That frustration is what led me here, because if language i

When I first published Swarm on GitHub, most questions weren't about Rust or MCP. They were about timing and categorization: "We just need a lightweight gateway for multi-provider routing; agents feel like overkill." "We already run an orchestration framework; why would we replace our proxy?" This reaction highlights a false dichotomy currently plaguing the AI infrastructure ecosystem: the assumption that a gateway and an agent orchestrator must be two completely different products. In practice, teams rarely wake up needing full-blown multi-agent autonomous swarms on Day 1. But when they start with a standalone proxy, they inevitably hit a wall — patching together Python microservices, external vector state stores, MCP bridges, and ad-hoc eval scripts. Every evolution requires a rewrite. The core premise of Swarm is different: a single, pure-Rust runtime where you don't choose between a gateway and an orchestrator — you simply choose which capabilities to turn on. The AI Adoption Ladder Most engineering teams evolve their LLM stack along a predictable trajectory: Rung 1: OpenAI-Compatible Gateway (Drop-in replacement for hardcoded SDKs) └── Rung 2: Multi-Provider Fallbacks (Groq, Gemini, Ollama, vLLM via TOML) └── Rung 3: Stateful Sessions (Previous response chaining & context) └── Rung 4: Native MCP Tools (SSE + Streamable HTTP tool execution) └── Rung 5: Multi-Agent DAGs (Planner + Executor + Specialists) └── Rung 6: Built-in Evals (LLM-as-a-Judge & policy gates) You can stop at any rung and have a lean, production-grade binary. When you're ready for the next level, you change a configuration flag — not your architectural foundation. Rung 1 — Just a Low-Latency Gateway If your immediate goal is simply eliminating hardcoded API keys and single-vendor SDK locks, Swarm acts as an OpenAI-compatible drop-in front door with sub-millisecond native routing overhead. # Spin up the gateway in seconds ./kickstart/gateway_kickstart/01_launch_gateway.sh curl -X POST http://loc

Your agent starts a run with cache_read_input_tokens at 40K and climbing. Twelve tool calls later, reads drop to zero and cache_creation_input_tokens jumps to the full conversation length — on every single turn. Nothing in your prompt changed. No timestamp, no reordered tool, no model switch. The prefix is byte-identical. You just hit the 20-block lookback window, and it is the single most expensive thing about Claude prompt caching that nobody puts in their retro. TL;DR A cache_control breakpoint searches backward through at most 20 content blocks to find an existing cache entry. One agentic turn with 11 parallel tool calls emits 22+ blocks and blows past that — the next request finds nothing and rewrites the whole prefix at 1.25x. Fix it by placing rolling breakpoints every ~15 blocks , not one marker on the last block. You get 4 breakpoints per request total; spend 1 on tools+system and rotate the other 3 through the message list. Invalidation is tiered , not all-or-nothing: tool_choice , images, and toggling thinking preserve the tools+system cache. Only tool-definition changes and model switches force a full rebuild. Changing the system prompt mid-run nukes everything downstream — unless you append a {"role": "system", ...} message to messages[] instead (Claude Opus 5, Opus 4.8, Fable 5; not Sonnet 5). input_tokens in the usage block is the uncached remainder only . Total prompt size is input_tokens + cache_creation + cache_read . Dashboards that graph input_tokens alone will show you a flat line while you burn cache writes. Why does Claude prompt caching miss in the middle of an agent loop? Because cache lookup is bounded. Prompt caching is a prefix match on exact bytes, but a breakpoint doesn't scan the entire history for a matching entry — it walks backward a limited number of content blocks. That limit is 20. If the previous request's cached block is more than 20 blocks behind your new breakpoint, the lookup fails, and the API treats your request as cold ev

For a long stretch, the gap between the best closed, proprietary models and the best openly available ones was wide enough that it barely factored into most build decisions — you used the closed frontier model and accepted the cost and lock-in. That gap has been narrowing, and it's changing how teams think about model selection. What's actually narrowing Open-weight models have closed much of the distance on general reasoning and coding benchmarks that used to clearly favor closed frontier models. They're not universally equivalent — closed frontier models still tend to lead on the hardest reasoning tasks — but for a large share of practical use cases, the gap has stopped being the deciding factor it once was. Why this matters beyond benchmarks Self-hosting becomes viable for teams with real data-residency or cost-at-scale requirements Negotiating leverage shifts — closed model providers face real competitive pressure on pricing when a credible open alternative exists Fine-tuning your own model for a narrow domain becomes a realistic option rather than an expensive research project The tradeoffs that remain Open-weight models shift the burden from "pay per token" to "own your infrastructure" — serving, scaling, and maintaining your own deployment is genuinely more operational work than an API call. For many teams, that tradeoff isn't worth it even with comparable model quality; for others, especially at high volume or with strict data requirements, it increasingly is. The strategic shift this creates Model selection is becoming less of a one-time architectural decision and more of an ongoing evaluation — teams increasingly benchmark both closed and open options against their actual workload periodically, rather than committing to one provider indefinitely. The competitive pressure from open-weight progress is a meaningful part of why that flexibility has become worth building for. Where this heads Expect the closed/open distinction to matter less over time as a bina

3.1 Introduction The previous chapter explained how a user request flows through the Adaptive Cognitive AI (ACAI) architecture. This chapter focuses on the internal engineering components that make the architecture possible. Unlike a traditional chatbot, ACAI is designed as a collection of independent but coordinated modules. Each module has a clearly defined responsibility, communicates through structured interfaces, and can be improved independently without redesigning the entire system. This modular approach follows established software engineering principles such as separation of concerns, maintainability, scalability, and testability. 3.2 System Components The complete ACAI architecture consists of the following primary components. ┌──────────────────────────────────────────────┐ │ USER INTERFACE │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ API GATEWAY & AUTHENTICATION │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ INTENT ANALYZER │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ GOAL ANALYZER │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ DYNAMIC TASK PLANNER │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ SEMANTIC MEMORY MANAGER │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ KNOWLEDGE RETRIEVAL ENGINE │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ CONTEXT OPTIMIZATION ENGINE │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ FOUNDATION LANGUAGE MODEL │ └──────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ MULTI-AGENT COORDINATOR │ └─────────────────────

Short answer: the best way to reduce LLM cost for a product catalog is to measure cost per accepted record, then route each job by difficulty. Count prompt tokens before the call, use a small model for the easy summarize/classify/extract-JSON cases, reserve a stronger model for exceptions, and batch work that can wait. The winning option is the one that preserves the required fields at the lowest cost per accepted result, not the one with the lowest token rate. I build RAG and agent features in Python, so I want this decision to survive contact with production. A catalog description such as “blue jacket, recycled nylon, sizes S–XL” looks easy until one tenant sends HTML, another sends translated attributes, and a third puts three products in one paragraph. The useful unit is therefore a tenant-scoped record with an outcome, a token count, a retry count, and a review decision. Start with the record, not the model For this workflow, the data path is short: normalize a description, count the tokens in the planned prompt, choose a route, request a typed result, validate it, and write the result and its cost to an append-only ledger. A rejected result must remain visible. Otherwise, a cheap model can appear successful simply because invalid JSON and missing attributes disappeared from the report. The ledger needs enough identity to answer a boring but important question: which tenant paid for this retry? I use a job ID, tenant ID, source revision, model route, input token count, output token count, latency, validation status, and review status. Keep the raw description out of ordinary cost dashboards when it contains customer data; the ledger can hold a reference to the source revision instead. Prompt-token counting is a gate, not a decorative metric. If an HTML description expands the prompt beyond its budget, the worker can strip markup, split the record, send it to review, or select a different route. Those choices have different quality consequences, so record the re

Cryptographic Context Injection is only the latest way to break an LLM safety guardrail.

1. The question that started everything Three weeks into my internship, my supervisor sat down across from me and asked, very casually: "OK your NLP pipeline extracts intentions and rules from legacy Java. Nice. And then what? " I looked at him. I looked at my laptop. I looked back at him. The whole project — Pulsar Modernizer — was supposed to eventually turn legacy Java into modern Spring Boot code. My part was the "understand the old code" part. F1 = 0.857 on the annotated corpus, a shiny React UI, everything humming in Docker. But the "and then?" was doing a lot of work in that sentence. That evening I wrote in my notes: "Nobody has actually tried the generation part. Everyone assumes it'll be easy because LLMs. That is very obviously wrong." So I decided to try. 2. Why "just prompt an LLM to rewrite it" doesn't work The naive move — feed the old code and the extracted rules to an LLM and say "please modernize this" — has three problems and I hit all of them in the first hour: The model hallucinates. It happily invents helper classes that don't exist and calls methods with the wrong signature. You have no criterion for stopping. The model tells you "it's done ". OK. Is it? By what test? You have no criterion for equivalence. Even if it compiles, how do you know the new code actually does what the old one did? I needed something more constrained than "prompt it and pray". 3. The setup — a chain, not a monolith I ended up building three specialized agents in sequence: IntentCard + RuleCards │ ▼ [APIDesigner] ──► JSON contract (class, methods, DTOs, throws) │ ├───────────────┐ ▼ ▼ [CodeGenerator] [TestGenerator] │ │ ▼ ▼ .java *Test.java │ │ └────► verifier (mvn test) The key insight: each rule extracted from the legacy code should become a test that the generated code has to pass. This flips the whole thing. I don't trust the LLM. I trust javac and JUnit. I did all of this on a local model — Qwen 2.5 Coder 3B via Ollama. No cloud APIs, no data leaving my Mac. On a

2.6 Why Retrieval Is Necessary A Large Language Model only knows what was available during its training. If the user asks about something that changed after the model was trained, the model may not know the latest information. Instead of forcing the language model to guess, ACAI first determines whether external information is required. User Prompt │ ▼ Need External Knowledge? │ ┌────┴────┐ │ │ No Yes │ │ ▼ ▼ Continue Search Engine │ ▼ Document Ranking │ ▼ Source Selection │ ▼ Context Builder Internal Workflow The Retrieval Engine performs several sequential operations: Stage 1 — Query Generation The original user prompt is transformed into one or more optimized search queries. Example User Prompt Explain quantum computing. Generated Queries Quantum computing basics Quantum computing architecture Quantum algorithms Quantum hardware Instead of searching only once, multiple optimized queries increase the chance of retrieving relevant information. Stage 2 — Source Collection The retrieval system collects candidate documents. Possible sources include: • Internal Knowledge Base • Company Documentation • Scientific Papers • Technical Documentation • API Documentation • User Files • Vector Database Stage 3 — Ranking Not every document is equally useful. The Ranking Engine assigns a relevance score. Document A Score 96% Document B Score 91% Document C Score 72% Document D Score 44% Only the highest-quality documents move to the next stage. Stage 4 — Filtering The system removes: • Duplicate documents • Low-quality sources • Irrelevant information • Outdated documents The objective is to reduce noise before reasoning begins. 2.7 Context Optimization Layer One of the largest limitations of LLMs is the context window. Suppose the retrieval engine returns 500 pages. The model cannot efficiently process every page. Therefore ACAI introduces a Context Optimizer. Workflow 500 Pages ↓ Ranking ↓ Filtering ↓ Compression ↓ Important Facts ↓ LLM Instead of sending every token, only the

I built a pytest harness that runs the same set of questions through five language models at once - a free local Llama, plus GPT, DeepSeek, and two Claude models - and compares them on the three things a team pays for: cost per query, speed, and answer quality. The plan was simple. Run the grid, read the scoreboard, say which model to use. The scoreboard came back clean and easy to read. This is the story of why I didn't trust it, and what I found when I checked. The thing I stopped trusting wasn't any of the models. It was the tool I was using to score them. It's also the first project in this series that spends real money. Every one before it ran locally, for free. Here each call costs something, and the whole comparison came to about 21 cents. That price is small, but it changed how I tested, and not in the way I expected. The scoreboard, and why I didn't stop there Five models, the same ten questions, twice each, every call measured. Here is the run, ordered by quality score (a second model grades each answer on correctness and relevance, combined into a 0-1 score, pass line 0.7): model quality mean $/query mean latency out-tokens deepseek-v4-pro 0.970 $0.000138 2713 ms 113 claude-haiku-4-5 0.967 $0.000537 1597 ms 104 gpt-5.6-luna 0.962 $0.000082 1323 ms 65 claude-sonnet-5 0.937 $0.002426 4093 ms 239 llama3.2 (local) 0.922 $0.000000 7859 ms 130 Read it straight and it looks finished. The whole quality column sits in a tiny band, 0.92 to 0.97. The cheapest, fastest paid model scores right in there with the rest. The most expensive one, Sonnet, at about thirty times the price per query, sits no higher than the others - its answers are just longer (239 tokens to GPT's 65), which costs more and takes longer without scoring better. So the easy takeaway is: use the small cheap model, skip the expensive one. I want to be careful with that, because it's the kind of tidy result I've learned to distrust. The gaps between the top models are tiny, and a ranking built on tin