Sam Reghenzi Homepage

The Ontology Was Always a Bounded Context

2026-09-01T09:56:00+02:00

Two agents meet in a park.

"I've just had a complaint from a customer," says the first.

"What's a customer?" asks the second.

"Anyone with an account."

A third agent walks over.

"That's not a customer," it says. "A customer is anyone with an active subscription."

The three agents pause.

Nobody is wrong. Nobody is hallucinating.

They are just using the same word to mean different things.

And somewhere between them, an integration is about to break.

This is the failure mode that is currently being rebranded as "agents need ontologies." The diagnosis is right. The fix being marketed alongside it is not. That fix is a single shared ontology sitting above the agents, arbitrating meaning for everyone — and it's the wrong prescription for a problem that already has a name and a twenty-year-old solution. The name is Domain-Driven Design. It isn't showing up in this conversation because most of the people having it came from data and knowledge graphs, not from software architecture.

The problem is real and it's measurable

Start with the evidence, because the failure isn't hypothetical. OG-RAG, presented at EMNLP 2025, anchors retrieval to an ontology-backed hypergraph instead of a flat vector index. It reports a 55% jump in fact recall and 40% in answer correctness over standard RAG on the same corpus. A 2026 biomedical study went further. Grounding agent outputs against a domain ontology in RDF/OWL brought hallucination rates on clinical queries down from 63% and 48%, depending on the baseline, to 1.7% — with accuracy around 98%.

Numbers like that explain why every vendor with a graph database is suddenly an "ontology for agentic AI" company. They also explain why the instinct isn't wrong. Give an LLM-based system an explicit, checkable model of the domain it operates in, and it gets measurably more reliable. I made a version of this argument in The Guardrail Is Not in the Model: the check that catches an illegal state has to live outside the model, because a probability distribution cannot reliably remember a rule that was never written down.

What that post didn't answer is the next question, which is organizational rather than architectural. Whose ontology? Covering what? Owned by whom, and updated how? That's where the current wave of enterprise ontology platforms gives an answer I don't think holds up.

The diagnosis that keeps being wrong

The answer on offer — from Palantir's Foundry Ontology to Stardog to RelationalAI — is some version of: build one semantic model of the enterprise, wire every agent to it, and let it be the shared source of truth.

I have seen this movie. It's the Semantic Web, 2001 to roughly 2010, W3C-flavored instead of venture-flavored. RDF, OWL, a vision of universally linked data with formally specified meaning. Then a slow, expensive collapse. The reason it failed was never that formal semantics don't work; SHACL validators are boring, cheap, and effective at exactly the scale you point them at. It failed because getting an organization to agree on one model of everything is brutally expensive, and keeping that model true over time is worse.

The new version does have one genuinely different cost: authoring. An LLM can draft a plausible ontology from your documentation and schemas for a few cents, where a knowledge engineer used to bill for weeks. That's real progress. But authoring was never the part that killed the Semantic Web. Governance was — what happens once two teams' understanding of "customer" starts to drift apart in production. Cheaper to build is not the same as cheaper to own, and owning is where a global ontology dies.

DDD already named this problem

Here is what the ontology-for-agents conversation is missing: this is not a new problem. Eric Evans described it in Domain-Driven Design in 2003 — different parts of an organization using the same word to mean different things. His answer was never "build one model and force everyone onto it."

His answer was the bounded context: a model only has to be internally consistent within an explicit boundary. Inside the billing context, "customer" means "entity with an active subscription," full stop, and every rule is coherent under that definition. Inside the support context, "customer" means "entity with an account," and that's equally coherent on its own terms. The two contexts are not wrong relative to each other. They were never supposed to share a definition in the first place.

The ubiquitous language maps directly onto what an ontology actually is when it's working. It's not a separate artifact that sits above the code and gets synced with it by a process nobody enjoys. It is the vocabulary the domain experts and the model use, inside that one context, for that one purpose. An ontology that lives outside the bounded context it describes is exactly the kind of artifact DDD spent a book telling you not to build.

And when two contexts genuinely need to talk, DDD already has the vocabulary for that too. A shared kernel for the small slice of model both sides agree to co-own. An anticorruption layer when one side must consume the other's model without importing its assumptions. A partnership when two teams agree to evolve their contexts in step. Read the current papers on "multi-agent semantic interoperability" and you are reading context mapping with the serial numbers filed off.

Event-driven architecture already named the other half

Bounded contexts keep a local model coherent. They don't explain how contexts stay in sync without collapsing back into one shared schema. That half was solved by event-driven architecture.

The core discipline is treating an event as a fact, not a command: OrderPlaced, not PlaceOrder. A command presupposes that the receiver shares your model closely enough to know what to do with the instruction. A fact just asserts that something happened, in the vocabulary of the context that emitted it, and lets every consumer interpret it inside its own model. That is far looser coupling than a synchronous call between two agents that must agree, in real time, on one shared schema just to complete a request.

Event sourcing covers the other thing the enterprise-ontology pitch leads with: audit and accountability. A well-designed event log is already a complete, ordered, immutable record of every fact the system has asserted. That is precisely the traceability that Palantir and Stardog sell as the differentiated value of an ontology layer. You don't need a global semantic model to get an audit trail. You need an event log that nobody is allowed to mutate.

Which makes it a little dispiriting to watch the current agent stack rebuild what event-driven architecture spent twenty years moving away from. MCP, launched by Anthropic in late 2024, is a good protocol for what it does: a stable way for a model to discover and call a tool. But the pattern forming on top of it — and on top of LangGraph, CrewAI, and AutoGen — is a central orchestrator calling each agent synchronously, with a shared understanding of the payload assumed on both ends. Distributed systems spent two decades learning to prefer choreography over that. The agent stack is reinventing the thing we walked away from.

Explicit structure isn't a compromise, it's a multiplier

There's an objection worth taking seriously here: agents aren't microservices. A microservice's behavior is deterministic given its inputs; an LLM's isn't. Doesn't imposing a rigid schema on an inherently stochastic process miss the point?

It's the opposite. Precisely because the output is stochastic, giving it an explicit shape to land in is what makes it usable. This isn't hand-waving — it's what the numbers at the top of this post already showed. Constraining generation against an explicit ontology is what took the biomedical hallucination rate from the 50-60% range to 1.7%. Structure doesn't fight the model's nature; it compensates for it. A type system doesn't fight a language's flexibility either. It gives the parts that need to be reliable somewhere firm to stand.

There's a second benefit that's easy to undersell: introspection. An explicit, local ontology gives you a place to look when an agent's behavior needs explaining, in a way a free-text prompt never does. When an agent inside the billing context takes an action, you can ask which entities and relations it reasoned over, and check the answer against a schema — instead of re-reading a transcript and guessing. That extends the argument from The Guardrail Is Not in the Model one step further. The structure that lives outside the model isn't only a cage that stops bad states. It's an instrument that makes the good ones legible.

Who maintains it: the review loop, not the curator

The objection that actually matters is the one that killed the Semantic Web: someone has to own this thing over time, and ownership is expensive. DDD's answer was never "write the model once." A mature bounded context goes through model refinement as the team's understanding deepens. The ubiquitous language evolves because the domain does, not because someone forgot to finish it the first time.

What's different now is who drafts the refinement. In the expert-systems era, and in the Semantic Web's, a human had to notice the drift, understand it, and hand-author the fix. Today the agent itself can be the one to notice. It can flag the cases where its actions kept getting rejected by the local schema, or where two contexts' events stopped lining up, and propose a specific, scoped patch to the local ontology. A human still reviews and merges the diff. What disappears is the step where a person has to notice the drift unassisted and draft the fix from a blank page.

Note the constraint doing the work here: the patch is scoped to one bounded context, not to a global model. That's what keeps the loop tractable. This is a real reduction in the maintenance cost that killed the last two attempts at formal semantics, and it only exists because the thing being maintained is small.

The provocation

None of this requires a new discipline called "ontology engineering for agentic AI." It requires applying to agents the discipline distributed systems already have. Give each agent a bounded context and an explicit local model, not a slice of a shared global one. Connect contexts with events that are facts, not commands that presuppose a shared schema. Run a periodic, LLM-assisted refinement loop instead of pretending the model will be right forever once you've paid to build it.

So before buying a platform that sells itself as "the enterprise ontology layer for your agents," ask a blunter question: is the missing piece really a new epistemic layer, or is it a bounded context design, an event bus, and a review process you haven't built yet? In most of the failures I've seen, it's the second one. And it was always going to be cheaper.

The Guardrail Is Not in the Model

2026-08-30T14:16:00+02:00

Frank Coyle gave a twenty-minute talk at the AI Engineer World's Fair that has been circulating for a few weeks now, and the argument in it is simple enough to state in one sentence: agentic systems need ontologies, because LLMs are probabilistic and probabilistic systems need logical guardrails.

I think he is right, but the interesting part is why, and that is easier to see if you start from the failures rather than from the ontologies.

The failure that isn't a hallucination

Take a support agent that handles refunds. A request comes in, the agent reads the order, calls the payments tool, and refunds €340 to the customer. The tool call is well-formed, the arguments validate, and the summary it writes afterwards is an accurate description of what it did. The problem is that the same order had already been refunded four days earlier.

It is worth going through the layers that should have caught this, because none of them did. The model did not hallucinate, since it never stated anything false. Schema validation passed: the amount was a positive decimal, the order ID was a UUID, and the reason was one of the allowed values. The eval suite passed too, because it scores the agent's output for helpfulness and faithfulness, and as a piece of text the response was fine. The system prompt did say not to issue duplicate refunds, and the model would have confirmed that rule if you had asked it.

The failure was not in the language. It was that "an order has at most one refund" is a rule of the business that existed only in the heads of a few engineers and in the implicit assumptions of some older database queries. It was never written down anywhere a machine could check it.

Most agent incidents I have seen have this shape. They are not fabrications, they are illegal states that nobody had written down. A payout goes to a support rep instead of the buyer because the recipient field was typed as a string. An order ends up with the status probably_shipped because the tool accepted free text. A category becomes its own ancestor because nothing said the relation was acyclic.

The usual responses to this all have something in common. Longer system prompts, more context, better retrieval, another round of fine-tuning: every one of them is a change inside the model, and every one asks a probability distribution to reliably avoid a state that was never defined. It is an attempt to solve a logical problem with more probability.

The loop is where the power and the risk both come from

There is a point in Coyle's talk that puts this in a useful frame.

In 1966 Böhm and Jacopini proved that any language with three constructs — sequence, conditional, and iteration — can compute anything computable. The then-current argument about whether Fortran or COBOL was the better language was therefore beside the point, since both had all three.

Until recently an LLM call gave you sequence and, with tool use, something like a conditional. Then we added the loop, in the form of while stop_reason == "tool_use". That third construct is a large part of why agents can now do things that a 2023 chat interface could not.

Along with the power we inherited the familiar problems of loops. They can fail to terminate. They can drift, with small errors compounding so that each turn is slightly further from the goal than the last and no single step looks wrong. They can consume an unbounded amount of money, which is why token budgets exist.

So we have a Turing-complete system whose transition function is a neural network, operating over a state space that was never formally specified, and our main way of constraining it is a system prompt written in English.

That is not a criticism of LLMs. It is the same reason we do not secure a web application by asking people in the documentation not to attempt SQL injection. A constraint that the system has to pass through is different in kind from a constraint the system is asked to remember.

What an ontology is, in practical terms

The word carries a lot of philosophical history, from Aristotle's categories through Quine to the Semantic Web work of the 2000s. Coyle sensibly reaches for Gruber's 1993 definition, a formal specification of a shared conceptualization. For engineering purposes it can be made more concrete than that.

The first part is a graph: entities, the relations between them, and properties on both. Order, Customer, Refund, SupportRep, refundOf, paidTo, status. If you have ever drawn your domain on a whiteboard, you have already done most of this work.

The second part is a set of constraints that sits beside the graph rather than inside it. This is the part that usually gets skipped, and it is where most of the value is. Graph technology lets you state things about the shape of the graph and then check them mechanically: that status takes one of exactly three values, that an Order has at most one Refund, that the recipient of a payout must be a Customer and that nothing is ever both a Customer and a SupportRep, that parentCategoryOf is transitive so a category cannot end up inside itself.

Some of these statements let you derive facts that were never written down. If the source of teaches is always a Teacher, then the single assertion "Bob teaches Scooter" tells you that Bob is a teacher and Scooter a student without either being stated. Other statements let you reject a state. Both are useful, and they are not the same operation, which matters later.

The structural point is that these rules live neither in the data nor in the weights. Not in the rows, because a relational schema can express a foreign key but not "at most one refund per order across these three tables." Not in the model, because fine-tuning adjusts a distribution rather than adding a decision procedure. They live in a third place, and that third place can be checked cheaply by ordinary code.

That is the architectural argument. The rest is implementation.

This has been tried before

If this sounds familiar, it should. It was tried in the 1980s and it failed.

Symbolic AI then meant expert systems: knowledge engineers sitting with domain experts, extracting rules and encoding them by hand. A lot of money went into it, Japan launched the Fifth Generation project, and then the field collapsed into the AI winter. The usual summary is that it did not scale.

Coyle mentions this and moves on, but the reason it did not scale is worth pausing on, because it determines whether we are about to repeat the mistake.

Expert systems did not fail because formal logic is useless. They failed at knowledge acquisition. The bottleneck was a person translating a domain expert's tacit knowledge into rules, one rule at a time, and then maintaining those rules as the domain changed underneath them. The reasoning was the cheap part. Getting the knowledge in was the hard part.

That is precisely the part that has changed. An LLM is good at reading unstructured material — tickets, documentation, transcripts, code, schemas — and proposing structure from it. A validator is good at the thing LLMs are bad at, which is saying no reliably.

So the division of labour has swapped. In 1985 humans did the acquisition and machines did the inference. Now the model does the acquisition and the machine does the verification, with humans reviewing a diff rather than authoring a corpus. That is a different bet from the one that failed.

There is a cost that tends to go unmentioned, though: someone has to own the ontology. When the business introduces partial refunds, "at most one refund per order" stops being true, and if nobody updates the rule the guardrail starts blocking legitimate work. A stale ontology is worse than no ontology, because it fails on correct behaviour and the team learns to route around it. This is a schema, and schemas need owners and a migration process.

Where it goes in the loop

Here is the agentic loop, with the place for the check marked.

import anthropic

client = anthropic.Anthropic()
messages = [{"role": "user", "content": user_request}]

while True:
    response = client.messages.create(
        model="claude-opus-5",
        max_tokens=16000,
        thinking={"type": "adaptive"},
        tools=TOOLS,
        messages=messages,
    )

    if response.stop_reason != "tool_use":
        break

    messages.append({"role": "assistant", "content": response.content})

    results = []
    for block in response.content:
        if block.type != "tool_use":
            continue

        # 1. Shape. Pydantic at the door: is this even the right type?
        try:
            args = TOOL_MODELS[block.name].model_validate(block.input)
        except ValidationError as e:
            results.append(error_result(block.id, f"Invalid arguments: {e}"))
            continue

        # 2. Effect — computed, NOT committed. Pure function, no side effects.
        proposed = TOOL_IMPLS[block.name].propose(args)

        # 3. Legality. The ontology at the ledger: is this state allowed?
        verdict = ontology.check(proposed.as_triples())
        if not verdict.ok:
            results.append(error_result(block.id, verdict.explain()))
            continue

        # 4. Only now does anything leave the process.
        results.append(ok_result(block.id, proposed.commit()))

    messages.append({"role": "user", "content": results})

Coyle has a good way of summarising this: Pydantic at the door, the ontology at the ledger. The two answer different questions. Pydantic asks whether the arguments have the right shape, so that a decimal appears where a decimal belongs. The ontology asks whether the resulting state is legal, and that question can only be asked about the proposed effect rather than the arguments. This is why step 2 has to be a pure function. An agent that writes to the database and then validates has already lost the ability to refuse; the check has to happen while the action is still a hypothesis.

The other thing worth noting is what happens on rejection. The verdict goes back to the model as a tool result together with an explanation, so the agent is told that its move was not allowed and why, and it takes another turn. Nothing crashes. If the same rejection repeats, escalate to a human.

The validator itself is short:

from rdflib import Graph
from pyshacl import validate

DOMAIN = Graph().parse("shop.ttl", format="turtle")           # the graph itself
SHAPES = Graph().parse("shop-shapes.ttl", format="turtle")    # the constraints

def check(proposed_triples: Graph) -> Verdict:
    # Merge the proposed effect into the domain graph and ask whether the
    # result is a legal world. Nothing here touches the database.
    g = DOMAIN + proposed_triples
    conforms, _, report = validate(g, shacl_graph=SHAPES, advanced=True)
    return Verdict(conforms, report)

# shop-shapes.ttl
:OrderShape a sh:NodeShape ;
    sh:targetClass :Order ;
    sh:property [
        sh:path :status ;
        sh:in ( "paid" "shipped" "refunded" ) ;   # kills probably_shipped
        sh:maxCount 1 ;
    ] ;
    sh:property [
        sh:path [ sh:inversePath :refundOf ] ;
        sh:maxCount 1 ;                            # kills the second refund
        sh:message "Order already has a refund." ;
    ] .

:PayoutShape a sh:NodeShape ;
    sh:targetClass :Payout ;
    sh:property [
        sh:path :paidTo ;
        sh:class :Customer ;         # kills the payout sent to a support rep
        sh:minCount 1 ;
        sh:maxCount 1 ;
    ] .

This is where the distinction between deriving and rejecting starts to matter, because most graph tooling was designed for the first of the two.

Graph technology grew up on the open web, where a graph is partial by construction: you hold a fragment of something larger, and the absence of a fact means unknown rather than false. Reasoners built on that assumption are generous. Tell one that an order can have at most one refund and then assert two, and it will not complain. It will conclude that the two refunds must be the same refund. That is sound reasoning under the assumption it was given, and it is the wrong answer here.

A refund ledger is the opposite kind of graph. It is closed and complete, and absence does mean false: if a second refund is not in it, there is no second refund. What you want for that is constraint validation rather than inference — cardinality, permitted values, required types — checked against a graph you have declared to be complete. That is what the shapes above do, and it is why the validator is short and contains no reasoner. Validation also produces a structured violation report, which is exactly what you want to hand back to the model as a tool result.

Inference is still useful for other things: transitive closure over a hierarchy, deriving types you did not assert, surfacing a contradiction you would not have thought to query for. Treat it as a second layer, added deliberately. The check that stops the duplicate refund is the validator, so if you build only one of the two, build that.

It is also worth not starting from scratch. schema.org has a substantial vocabulary for commerce, people and events, and reusing it means your ontology carries meaning outside your own codebase.

What this does not fix

An ontology does not make the agent smarter. It reduces the set of actions the agent can take without being stopped. Those are different properties, and the second one is the one you can verify.

It catches illegal states, not mistakes of judgment. A refund of €340 that should have been €34 is entirely legal: right type, right recipient, no duplicate, valid status. The ontology has nothing to say about it, and the same is true of a decision to refund a customer who was not entitled to one. Every constraint you can write down is a constraint you already knew, so the guardrail covers exactly as much as your explicit knowledge and no more.

That gives a reasonable scoping rule. If your domain has no constraints you can write down, this layer is not for you. A summarisation agent, a research assistant or a code explainer has no ledger and no illegal state, so validation only adds latency and maintenance. The technique is worth the effort where the agent moves money, changes records, sends things to people or drives a state machine — that is, where "wrong" has a definition that survives being written down.

That is a smaller set than all agents, but it is close to the set of agents people are currently trying to put into production.

The neuro-symbolic framing is fashionable, and I am generally wary of it because it usually arrives as an architecture diagram rather than as a claim you can test. The practical version is more modest: write down the rules of your domain in a form a machine can check, put the check between the agent's intent and its effect, and stop relying on the model to remember them.

The Baseline That Refuses to Die

2026-07-31T09:30:00+02:00

For roughly a decade, tabular machine learning had a boring, reliable answer. Someone would hand you a CSV — churn labels, credit defaults, sensor readings, insurance claims — and you would reach for a gradient-boosted tree. XGBoost, LightGBM, or CatBoost. Every eighteen months a deep learning paper would claim to have finally beaten the trees, practitioners would find the comparison unfair, and boosting would keep its throne.

That era ended sometime in the last twelve months, and it ended more decisively than most people realize. But the conclusion practitioners are drawing from it — stop using trees — is close to the opposite of what the evidence supports.

What actually changed

The venue for this argument is now TabArena, a living, Elo-rated benchmark over 51 curated tabular datasets with proper tuning protocols and repeated splits. It is the first tabular benchmark designed by people who had clearly been burned by bad tabular benchmarks.

On that board, tabular foundation models — pretrained transformers that do in-context learning over your rows, no gradient steps required — now hold every top single-model slot. In Prior Labs' own technical report, TabPFN-3 in its default configuration lands around 1677 Elo, with a "thinking" variant well above that; AutoGluon's four-hour multi-model ensemble pipeline sits at 1695. The best trees, tuned and post-hoc ensembled, come in around LightGBM 1440, CatBoost 1414, XGBoost 1387. On the small-data slice, the foundation model gets to a statistical tie with the four-hour AutoGluon pipeline in a single forward pass.

Then on June 30, 2026, Google Research released TabFM, a zero-shot tabular foundation model that also beats heavily tuned trees on TabArena — reportedly by solving the pretraining-data problem with large-scale synthetic table generation.

The comparison nobody runs

Here is the uncomfortable part. Almost every team that has "evaluated foundation models against XGBoost" this year did not run a comparison. They ran a demo.

The typical version looks like this: load the dataset, call a foundation model's predict, compare against an XGBoost with roughly default hyperparameters and a single train/test split, observe that the foundation model wins by two points of AUC, and write it up. This is exactly the mistake the tabular deep learning literature spent 2021–2024 making in the other direction, and it is worth being precise about the failure modes, because they compound.

Tuning budget parity. The two families have asymmetric returns on tuning: a foundation model's default is often within noise of its tuned version, while a GBDT's default sits well below tuned, and tuned-plus-ensembled is another step above that. "50 Optuna trials each" hands one side a budget it cannot spend and the other side less than production practice. State the budget in wall-clock or dollars, and report defaults and tuned separately.

Ensembling parity. Post-hoc weighted ensembling of configurations is nearly free accuracy and it reorders tabular leaderboards. If the challenger's number is 32 blended forward passes and the tree's is one fitted model, you are comparing a committee to an individual. Ensemble both or neither.

Split protocol and metric. Single splits on 5–50k-row tables have standard deviations large enough to swallow every effect size in this debate: use repeated CV, multiple outer seeds, confidence intervals on everything. If the intervals overlap you have a preference, not a result. And drop accuracy — score AUC-PR on imbalanced problems, and log loss or Brier plus a reliability curve wherever downstream decisions consume the probabilities. Trees and pretrained transformers calibrate differently, and a better-ranking, worse-calibrated model can win your benchmark while costing you money.

Pretraining contamination. The most under-checked failure of the new regime. For a model pretrained on a large corpus of tables, "zero-shot performance on a public dataset" is a claim about leakage as much as about generalization — the forecasting community built explicit non-leaking splits into GIFT-Eval and now flags leaking models on the board precisely because this bit them. If you are benchmarking on adult or covertype, you are not measuring what you think. Evaluate on your data; it is the only evaluation that answers your actual question anyway.

Cost as a first-class axis. Plot accuracy against serving cost. The numbers that matter are training time per 1,000 samples, prediction latency per row at your concurrency, and whether inference needs a GPU. On published TabArena timings foundation models are far cheaper to train than a tuned tree sweep, and trees are far cheaper to serve — which dominates depends on your retraining cadence and request volume, and no leaderboard can tell you that.

Where the gap comes from. Aggregate Elo hides the mechanism, and the mechanism is documented: the advantage concentrates under data scarcity and complex interactions, and erodes or reverses on large, predominantly numeric tables. Pretrained models bring learned priors over table structure; boosting extracts dataset-specific signal iteratively. Given enough rows, the boosting exhausts the available signal and the prior stops adding anything. Benchmark work keeps converging on the same conclusion — performance is driven by feature structure, not model complexity or row count — and CatBoost remains the safest pick when categoricals dominate.

A protocol worth actually running

If you want a defensible answer for your own problem, this takes an afternoon:

Fix the harness before you look at any model. Repeated stratified CV, ≥5 outer seeds, metrics derived from the downstream decision, confidence intervals mandatory.
Establish the floor. Logistic regression or a default random forest on your real preprocessing. Skipping this is how teams celebrate a foundation model that beat a broken pipeline — and a surprising number of "hard" problems turn out to be linear-plus-noise.
Establish the reference. LightGBM or CatBoost: defaults, then a fixed wall-clock tuning budget, then tuned-plus-ensembled. Three numbers, not one.
Add the zero-shot challenger. One forward pass from a tabular foundation model. Nearly free, and under ~10k rows it will often win outright.
Plot the frontier, don't rank the models. Metric against serving cost, then pick the point that fits your constraints rather than the top of a list.
Score the non-quantitative axes explicitly. Auditability, drift behaviour, retraining ergonomics, vendor dependency, deployability. Write them down as requirements before the numbers seduce you.

Step 6 is where foundation model pilots quietly die. In regulated settings — credit scoring, underwriting, clinical decision support — a documented GBDT with monotonic constraints, stable attributions, and a reproducible training run clears model risk review. A third-party pretrained transformer with opaque failure modes and a shifting version history is a much harder conversation, and you will have it again every time the vendor ships a checkpoint.

Time series is a genuinely different story

The tabular argument and the forecasting argument get conflated constantly, and they should not be. In forecasting, the split is not old-versus-new — it is about whether you have history.

For true zero-shot forecasting, pretrained models have a structural advantage that trees cannot replicate. Chronos, TimesFM, Moirai-2, Sundial, and TabPFN-TS all forecast a series they have never seen. Moirai-2 ranks near the top of GIFT-Eval among non-leaking models, trained on tens of billions of observations across many domains. If you have forty thousand new series with no usable history and need something serving tomorrow, that is where you start, and it isn't close.

But when you have sufficient in-domain history, exogenous covariates — prices, promotions, weather, calendar effects, holidays — and a hierarchy to reconcile, feature-engineered gradient boosting remains competitive and often better. The M5 pattern (one global GBDT over lag and calendar features across all series) has not been dethroned by anything for that class of problem. One striking data point: when Google DeepMind pointed an automated code-search system at GIFT-Eval, it outperformed the entire leaderboard — foundation models included — and the solutions it discovered converged strongly on gradient boosting and ensemble/decomposition methods. An unbiased search over the space of forecasting approaches walked toward boosting.

Recent work frames this as a break-even analysis rather than a ranking, which is the right frame: foundation models need GPU infrastructure, have opaque failure modes, and can underperform on highly domain-specific data, while boosting and classical smoothing methods are interpretable, run on CPUs, and carry decades of empirical validation. The break-even point is essentially a function of how much relevant history you have per series.

The constraint nobody budgeted for

There is an unglamorous reason this matters more in 2026 than it would have in 2024: GPUs are not a commodity you can assume.

The 2026 crunch is not one shortage but a stack of them — HBM, CoWoS packaging, wafer capacity, data center power, cloud allocation — all tight at once. Data-center GPU lead times are reported at 36 to 52 weeks, hyperscalers have locked up much of the allocation on multi-year commitments, and teams shut out of reserved pools land on on-demand pricing at multiples of budget. In some regions the binding constraint has shifted again, to grid interconnection.

This is not an argument that foundation models are bad. It is an argument that "needs a GPU at inference time" is a line item with scarcity risk attached, currently priced by the market rather than by your infra team. A model that serves at microsecond latency on CPUs you already own carries option value that appears in no accuracy table. If your churn model is a LightGBM on commodity hardware, capacity planning is solved; if it needs an accelerator per replica, you are competing for allocation against every LLM workload in your company — and losing.

So: what do you actually do

Keep a GBDT — LightGBM or CatBoost — as a mandatory baseline, permanently. Not out of nostalgia, but because it is the instrument that tells you whether your problem is hard or whether you are making it hard. It trains on a laptop, it tells you which features matter, and it will catch the leakage in your pipeline before a foundation model launders it into a suspiciously good score.

Add a zero-shot tabular foundation model as a second free shot. On small and medium tables it frequently wins with no tuning and the cost of finding out is one forward pass. Treat it as a strong candidate, not a replacement.

Random forests specifically occupy narrower ground than XGBoost does. They remain worth having for immediate baselining, for quantile-based uncertainty estimates, for small noisy datasets where boosting overfits, and as ensemble members. They are rarely the final answer any more.

And then decide on your data, with your metric, at your cost point — not on a leaderboard. The frontier is moving fast enough that any specific recommendation here has a shelf life of about two quarters. The evaluation discipline does not.

Sources

TabArena: A Living Benchmark for Machine Learning on Tabular Data — https://arxiv.org/pdf/2506.16791 · live board: https://tabarena.ai
TabPFN-3 Technical Report (leaderboard tables, timings) — https://arxiv.org/pdf/2605.13986
Hollmann et al., "Accurate predictions on small data with a tabular foundation model," Nature 637
Google TabFM release coverage and the ensembling caveat — https://ai-crucible.com/articles/tabfm-ensembling-wins-even-for-tables/
Tabular model benchmark across 19 datasets (feature-structure findings) — https://aimultiple.com/tabular-models
GIFT-Eval: A Benchmark for General Time Series Forecasting Model Evaluation — https://arxiv.org/abs/2410.10393
"When Do Foundation Models Pay Off? A Break-Even Analysis of Pretrained Time Series Forecasters" — https://arxiv.org/html/2607.04919v1
"An AI system to help scientists write expert-level empirical software" (GIFT-Eval result converging on gradient boosting) — https://arxiv.org/pdf/2509.06503
Schmitt, "Deep Learning vs. Gradient Boosting: benchmarking for credit scoring" — https://arxiv.org/pdf/2205.10535
GPU and compute supply constraints, 2026 — https://www.apollo.com/wealth/insights-news/insights/2026/06/growing-compute-shortage · https://vexxhost.com/blog/gpu-capacity-crisis-ai-infrastructure-2026/ · https://inflect.com/blog/data-center-power-shortage-2026-why-grid-capacity-is-now-the-bigger-constraint-than-gpus

Hardware Ate Software. But the Survivors Become Agents

2026-07-14T09:30:00+02:00

There's a piece going around called Software Ate the World. Now Hardware Is Eating Software, and it is good enough that I want to argue with it. The thesis is that the center of economic gravity in tech is sliding down the stack — toward the layers with the deepest physical constraints and the strongest control points: semiconductors, data platforms, and the inference engines that run open models. NVIDIA at ~75% gross margins. Hyperscaler capex heading toward $5.3 trillion by 2030. Application margins compressing from the 75-90% of the SaaS era down to 50-60%. The conclusion: stop betting on apps, start betting on silicon and data gravity.

Part of what makes the argument land is that the kind of hardware underneath us has changed. For twenty years the substrate was commodity: RAM, CPU, disk — parts that were cheap, interchangeable, and evolving slowly enough that nobody thought about them. You provisioned them and forgot them. The AI stack runs on GPUs, and GPUs are a different animal entirely: faster-moving on the evolutionary curve, far more expensive, and carrying a margin the commodity components never did. When the foundation stops being fungible and starts being a scarce, high-margin, fast-obsolescing asset, it's natural to conclude that this is where the money now lives. That shift is real, and it's the strongest part of the article.

I agree with almost every number. I disagree with where the arrow points.

What the article gets right

Let me not build a strawman. The diagnosis is correct in two important ways.

First, value is migrating. The comfortable two-decade assumption that the application layer is where money accretes is genuinely breaking. If your product is a thin wrapper over a model call, your margin is a rounding error on someone else's capex.

Second — and this is the part people flinch at — point software is condemned. The single-purpose tool, the app that does one thing behind a form and a database, is being squeezed exactly as the article says. That compression from 90% to 50% margins is real, and it isn't a blip. So far, so aligned.

Where I get off the train is the prognosis. The article measures where the capital is going and assumes that's where the value will be captured. Those are not the same thing.

Capital intensity is not value capture

The whole argument rests on a slide from "this layer is expensive and physically constrained" to "this layer captures the value." But capital intensity and value capture are different axes. Railroads were brutally capital-intensive; most of the durable value ended up with the businesses that ran on top of the rails, not the ones that laid them. Being hard to build is not the same as being where the margin lives.

Here's the move the article misses: commoditization at the bottom doesn't destroy value, it relocates it. When a layer gets cheap and abundant, the barrier drops and value floods into whatever sits on top and can now do something new.

I keep bumping into this in practice, not in theory. A few months ago I ran Gemma 4 31B on a 32GB Apple Silicon Mac with Ollama. No tokens, no API bill, no hyperscaler in the loop. The article would file that under "inference commoditizing, margins compressing." Fine. But look at what commodity inference actually did: it put a capable model on my desk and collapsed the cost of building something on top of it to roughly zero. That is not value destruction. That is the barrier falling — and value doesn't evaporate when a barrier falls, it moves to whoever is standing on the other side of it.

The open-vs-closed gap closing from 8% to 1.7% in a year is the same story told as a threat. The article reads it as "models are commoditizing, so the value sinks to whoever owns the compute." I read it as "the intelligence layer just became a utility, so the interesting question is what you build with a utility."

The layer the thesis forgot

The article has five layers: semiconductors, open models and inference, premium models, data platforms, applications. Notice what's missing. There is no layer for the thing that turns a commodity model into something that does work in the world. No orchestration. No integration. No agent.

That omission is the whole disagreement in one gap.

Because the honest thing to say about point software is not that it's dying — it's that it's metamorphosing. The app stops being a static interface you operate and becomes an agent that operates on your behalf. Features stop being screens and become capabilities the agent can reach for. The value was never in the form and the database; it was in the judgment about what to do next, and that judgment is exactly what an agent embodies.

This is not a slide deck abstraction for me. It's most of what I've been writing about. The reason I keep picking at MCP versus skills, or at the way OAuth cracks when you hand it to a model with no eyes and no hesitation, is that this is the scaffolding of the agent layer. How a model reaches the outside world, what it's allowed to touch, how it holds a session — those aren't plumbing details below the value. In an agent-shaped world they are the value.

Where gravity actually climbs

So if the bottom of the stack is commoditizing — and it is — where does the gravity go?

Not the GPUs. You can rent those by the hour, and the whole thrust of open models and local inference is to make the raw intelligence a fungible input. Owning silicon is owning the railroad.

The new control points are further up:

Orchestration — the logic that decides which capability to invoke, in what order, and how to recover when a step fails. This is genuinely hard and genuinely defensible, and it lives nowhere in the five-layer map.
Proprietary data loops — the article actually gets this half-right under "data gravity," but frames it as a moat for platforms rather than the fuel that makes an agent good at your specific problem.
Agent reliability and safety — the boring, unglamorous work of making an autonomous thing trustworthy enough to hand real permissions. Whoever solves this owns a lock-in that no amount of capex buys.

None of these are cheap in capital. They're expensive in judgment, in data, and in the accumulated scar tissue of making agents behave. That's a different kind of moat than a fab, and it accrues to a different kind of builder.

The engineer's version of the thesis

The article is written for an investor: it's a map of where to allocate capital across a stack. Read it as an engineer and the question changes — not "where do I put my money" but "where do I put my effort." And once you flip that lens, almost every conclusion inverts with it.

If you believe — as I do, and as the argument that software becomes agents rather than standalone tools lays out — that every app worth keeping is going to become an agent, then the commoditization of hardware and inference isn't the headline. It's the precondition. Cheap, abundant, ownable intelligence is the raw material. The investor sees a low-margin commodity and walks away. The engineer sees a free input and asks what can finally be built now that it costs nothing. Those are opposite reactions to the same fact, and only one of them ships anything.

So let me be concrete about what building in an agent-shaped world actually looks like, because "software becomes agents" is easy to say and easy to get wrong.

The interface inverts

The oldest assumption in application software is that a human drives and the software responds. You click, it reacts. Every screen, every form, every menu is scaffolding for a person operating a machine. The agent inverts this: the software drives, and the human sets intent and supervises. That is not a UI refresh — it's a different center of gravity for the whole system. The screen stops being the product. The product is the loop of perceive → decide → act → check, and the screen is just one place a human can peek into it.

Practically, this means the work you used to pour into the front end — the state management, the wizard flows, the careful choreography of what the user can click next — largely evaporates or moves. What replaces it is the design of the agent's capability surface: the set of actions it can take, described well enough that a model can choose between them correctly, with the guardrails that keep a wrong choice from being catastrophic. That is engineering work, and it's harder than the front end it replaces, because your "user" now has no eyes, no common sense, and no hesitation.

Features stop being screens and become tools

In the old model, a feature is something you build and then teach a human to find: a button, a settings page, a documented workflow. In the agent model, a feature is a tool the agent can reach for — and the entire discipline of exposing tools to a model is exactly the terrain I keep writing about. Whether you reach for MCP or a plain CLI skill is not a plumbing decision underneath the value. It is the product surface. Get the tool descriptions wrong and the smartest model in the world invokes the wrong capability at the wrong time. Get the permission boundaries wrong and you've handed an OAuth token to something with no judgment about when to use it.

This is where the article's five-layer map fails an engineer most concretely. There is no line item for "the contract between the agent and the world," and yet that contract is where most of the real engineering — and most of the real defensibility — now lives.

What you actually invest in

If effort is the currency, here is where I'd spend it, in order:

The capability layer. The tools, their descriptions, their boundaries, their failure modes. This is the new API design, and it's the highest-leverage code you'll write.
The data loop. Not "data" as a static asset the way the article frames data gravity, but the loop: the agent acts, the outcome is captured, and that outcome makes the next action better. An agent with a tight loop on your specific problem beats a bigger model with none. This is a moat you build, not one you buy.
Reliability and evals. The unglamorous scaffolding that tells you whether the agent is getting better or quietly regressing. In an agent-shaped product, your test suite is a behavioral one, and building it is most of the job.
Model-agnosticism. Precisely because the intelligence layer is commoditizing, you should treat the model as a swappable part. The day I ran Gemma on a Mac I wasn't proving a Mac can host a model — I was proving the model is a component I can source three different ways. Build so that swapping it is a config change, not a rewrite, and the commoditization the article mourns becomes leverage you own.

Notice what's not on that list: owning the silicon, training a frontier model, betting the company on a fab. Those are capital plays, and they belong to people with capital. The engineer's plays are all further up — and they compound with judgment and data, which is the one kind of moat that gets deeper the cheaper the hardware underneath it gets.

The product is the job

Everything above is about how you build. But the sharpest way to feel the shift is to look at what you sell. SaaS sells software: a tool your customer's team logs into and operates. Agent SaaS sells work: you take a job the customer's team currently does, you package it whole, and you sell the outcome as a service. The team stops operating a tool and starts handing off a responsibility.

It sounds like a small rewording. It changes everything about how both sides think. The buyer stops evaluating features and seat counts and starts asking a much simpler question — "will this reliably get the job done?" — the same question they'd ask when hiring. And the builder stops shipping capabilities and hoping the customer assembles them into value; you're now on the hook for the value itself. That's a heavier promise, and it's exactly why the margin follows it back up the stack. Nobody pays SaaS-commodity prices for something that shows up, does the work, and is accountable for the result.

This is also why the commoditization the article mourns is a tailwind here, not a threat. When the intelligence underneath is cheap and abundant, the cost of doing the job collapses — and the price you can charge is anchored to the human labor you're replacing, not to your compute bill. The gap between those two numbers is the whole business.

What this looks like in the wild

The pattern is already shipping, and the tell is that these products don't describe themselves as software at all — they describe themselves as a role.

Slang AI sells an "AI super host" for restaurants. It answers the phone, manages reservations, routes VIPs to a human, and pings staff when something needs attention. Nobody at the restaurant logs into a dashboard to "use the reservation feature" — the phone just gets answered, all of it, every time. The product is the host.

Same Day does the equivalent for home services: AI dispatchers and receptionists that answer calls, book jobs, and reschedule without a human touching them. Again, the sale isn't a tool — it's the front desk.

What makes both work is the bar they clear: handle one genuinely annoying job better than a junior hire, faster than an agency, and cheaper than new headcount. That's the whole value proposition, and notice it's measured against people, not against other software. That's the giveaway that these aren't apps anymore. You don't benchmark a SaaS tool against a receptionist. You benchmark an agent against one — because it's doing the receptionist's job.

The prognosis, flipped

So yes: software ate the world, and now hardware is eating software. But something always crawls out of the thing that got eaten. This time it's the agent — and it's standing on all that cheap silicon, using it, not being replaced by it. The article looked down the stack and saw where the capital sinks. Look up the stack and you see where the work goes, and the work is where builders have always eventually captured the value.

The point software is dying. Long live the agent.

OAuth's Original Sin: Why MCP Inherited a Problem Designed for Humans

2026-06-19T22:48:00+02:00

Two posts ago I drew what felt like a clean line: MCP earns its keep when text and shell are genuinely insufficient — and one of the canonical examples I gave was "holding an OAuth session." It still is. But it is also the case I most undersold. Because OAuth, the protocol now standing under every serious MCP integration, was not designed for what we are about to do to it.

OAuth was designed for a human, sitting at a keyboard, reading a consent screen, clicking Allow. Every layer of the protocol — the browser redirect, the authorization code that crosses domains, the refresh token that lives on a device the user controls — presumes that human in the loop. MCP quietly removes them. What remains is the protocol, the tokens, and a language model holding both.

This post is about what happens when you take a security architecture designed for a conscious human and run it under software that has neither eyes nor hesitation.

The protocol that assumed a human

It is worth saying out loud, because the assumption is so deep we no longer notice it: OAuth is a protocol whose defensive mechanisms only work because a person is paying attention.

The standard story names three actors — resource owner, client, resource server — but the protocol's whole defensive posture is built around a fourth, implicit actor: a conscious human in front of the client. The redirect URI matching only matters because someone might notice the URL bar is wrong. The consent screen only works because someone reads "this app would like to access your calendar" and decides whether that is acceptable. The scope display only protects you if you scan the list. Even refresh tokens were designed with the unstated assumption that long-lived background activity would be rare, deliberate, and visible to the user whose token it was.

Take that human out, and OAuth still runs — but most of what made it safe stops working.

Now name what removed them. Not malware, not a clever new attack class. An interface change. We replaced "person, browser, consent screen" with "agent, MCP client, system prompt." The protocol below didn't change. The contract above did.

What MCP inherited

To MCP's credit, it inherited the best version of the contract available. The current authorization spec — building on the November 2025 revision — rests on OAuth 2.1 with mandatory PKCE, RFC 9728 for Protected Resource Metadata, and RFC 8414 for Authorization Server Metadata. Implicit grant is banned. Plain PKCE is banned. Bearer tokens in URLs are banned. Refresh tokens must be rotated or sender-constrained. Redirect URIs require exact-string matching. The June 2025 revision pulled token issuance out of MCP servers entirely and re-modelled them as OAuth resource servers, deferring identity to external providers where it belongs.

These are good choices. None of them, however, addresses the new asymmetry. They address the old failures of OAuth — the ones discovered when humans were still at the controls. The MCP spec doesn't yet have a vocabulary for the failures introduced by removing the human, because the protocol underneath doesn't either. What it has is patches, applied as those failures surface.

The cracks: four assumptions that break

If you look at the MCP-OAuth interface as a system of assumptions, four of them stop being true the moment an LLM agent sits where the human used to. None of these is theoretical; each maps to incidents already in the wild.

Consent comprehension. The user signs a consent screen listing scopes. They never see the superset of tools the agent might invoke during the session — and they couldn't, because the superset is constructed dynamically by the agent's reasoning, not by the consent UI. The consent screen was designed to summarise a page. It was never designed to summarise an agent's reasoning surface. The user clicks Allow on a list of capabilities; the agent treats Allow as permission to compose those capabilities in arbitrary ways the user never anticipated. The same scopes the user understood on the consent screen mean something different by the time the agent uses them.

Token custody. In the browser model, the access token lives in cookie storage, a keychain, a secure enclave — somewhere the user controls and can wipe. In the agent model, the access token lives, at least during use, inside the model's context window. Which is to say: in the same channel that can be prompt-injected. The token is co-resident with untrusted input. This is not a hypothetical: Supabase's Cursor integration was demonstrated in 2025 to be exfiltratable via prompt-injected support tickets that instructed the agent to surface its own credentials. The token wasn't stolen by a network attacker; it was asked for by the data the agent was processing.

Scope locality. A human uses a token on the site they authorised it for. They opened the tab; they will close the tab; the token's relevance is bounded by the user's attention. An agent uses tokens wherever they help solve the task. Cross-tool reasoning means an MCP server's token may be referenced, summarised, or — most worryingly — paraphrased into other tool calls without anyone explicitly composing those flows. OAuth's mental model assumes a token stays where it was granted. Agents do not respect that geometry.

Session presence. Humans close tabs. Agents do not. Refresh tokens were designed with the assumption that long-lived background activity is rare and visible. With agents, long-lived background activity is the default, and visibility depends entirely on logging the user may or may not have set up. The implicit dead-man's switch of "the user got bored and walked away" is gone.

These four cracks are the post's load-bearing argument. Everything that follows — the spec's evolution, the real attacks, the open questions — is illustration.

Zoom-in 1: anatomy of a real one-click takeover

The cleanest illustration of how these assumptions fail in production is the work disclosed by Obsidian Security between July and August 2025, with patches landing through September.

The pattern was depressingly common. Several well-known remote MCP servers had been implemented as OAuth proxies: the MCP server stood between the user's client and an upstream SaaS authorisation server (a productivity tool, a developer platform, a comms app), forwarding the OAuth dance and brokering tokens. To talk upstream, the MCP proxy used a single static client_id — shared across all users of that MCP server.

Three additional design choices, each defensible in isolation, combined into a one-click takeover:

The shared client_id meant the upstream auth server, once any user had ever consented, treated subsequent authorisation requests as already-approved. No fresh consent prompt; just a returned code.
The MCP proxy's redirect_uri matching was loose — substring or prefix, not exact — and accepted callback URLs the attacker could control.
The OAuth state parameter, whose entire purpose is to bind a callback to the user session that initiated it, was not strictly bound to that session.

The attack was a single crafted link. The victim clicks. The MCP proxy initiates the upstream OAuth dance. The upstream server, recognising the shared client_id as already-consented, returns an authorisation code without a prompt. The MCP proxy redirects to a URL that looks like one of its own but actually routes to the attacker. The attacker exchanges the code. One click. One account.

Read carefully, this is not a story about sloppy vendors. Each of those design choices made sense in a world where consent screens, redirect URI matching, and state were doing the human-supervised work they had always done. It is a story about a protocol whose safety mechanisms degrade in silence when the human is removed.

The November 2025 spec update introduced CIMD (Client Instance Metadata Document) precisely so each client instance can be uniquely identified at the protocol level, ending the shared-client_id failure mode at the source. It also tightened guidance on redirect URI matching and session-bound state. The patch is good. What it patches is not a bug; it is a category of assumption.

Zoom-in 2: the DCR dilemma

If the takeover story is the sharp edge of MCP-OAuth, the second zoom-in is the blunt one — a tension that has no resolution, only positions on a spectrum.

Dynamic Client Registration (RFC 7591) lets a client register itself with an authorisation server at runtime, receiving a client_id and credentials without human paperwork. For agents, this is almost a necessity: agents spawn ephemerally — in dev environments, in CI, in user sessions, in transient containers — and pre-registering each instance does not scale. The MCP spec permits DCR for exactly this reason.

Most enterprises block DCR. Also for good reason: anyone who can reach a registration endpoint can mint a client and start requesting tokens. In a world of registration flooding and client impersonation, the simplest defensive posture is "no one registers a client we did not approve in advance."

Both positions are correct. They are correct about different things. The agent-friendly position is correct about how the world actually wants to compose ephemeral software. The enterprise position is correct about how identity surface area becomes attack surface. The spec cannot tell either of them they are wrong.

What the spec did, in November 2025, was step back. DCR moved from "SHOULD-implement" toward "optional, with explicit guidance for gated deployments" — software statements, redirect domain allowlists, IP-restricted registration endpoints. This is not the protocol picking a winner. It is the protocol acknowledging that no answer is right for every deployment, and codifying the seam where the trade-off lives.

I find this the most honest moment in the MCP auth spec's short life. Specifications normally pretend the world has one answer. This one admits the world has a dial, and tells you where the dial is. That is a sign of a community learning in public.

What's still open

The November 2025 spec closed the worst-known leaks. The deeper question is unsolved, and it is older than MCP: what is an agent's identity?

Not the client software — one client may serve many sessions, many users, many models. Not the user — the user is the resource owner; the agent acts on their behalf but is not them. Not the model — models change between turns; multiple models may chain on a single task. None of OAuth's existing slots fit. Work like the Agent Identity Protocol (arXiv 2603.24775) is starting to take the shape of the question seriously, and the field broadly recognises that something between "machine identity" and "delegated user identity" is missing from the standard kit.

Until that work matures, MCP auth is doing what every protocol does when the world outruns it: bolting on constraints where the missing concept used to live. CIMD is one such bolt. The DCR downgrade is another. So is the resource-server reframing of June 2025. Each fix is a sentence that ends with "…because there is no human here anymore."

The thing I keep coming back to, when I read these spec revisions side by side, is how much of what made OAuth feel safe was never actually written down. For something like twenty years the protocol quietly relied on a kind of partnership with the person sitting in front of the browser. They were the one who noticed when a URL didn't look right, who paused in front of a consent screen and asked themselves whether the application on the other side was really the one they had meant to visit, who eventually closed the tab and turned a long-running session into a finished one. None of this was in the RFCs, and yet a surprising amount of the protocol's real-world safety lived there.

What MCP has done, almost as a side effect of solving a quite different problem, is dissolve that partnership. The parts of OAuth that were always specified — the flows, the cryptography, the metadata documents — are still there, working about as well as they ever did. It is the unspecified part we have lost, and we now find ourselves in the slightly awkward position of trying to write down, in protocol form, what used to be carried by attention.

I find this an interesting kind of work to watch. The November 2025 revision, with its per-instance client identities, its more careful handling of redirect URIs, and its quiet downgrading of dynamic client registration, is doing something specifications rarely do well: admitting that earlier choices had encoded assumptions the world has since invalidated. Some of these new mechanical constraints will hold up. Others, I suspect, will turn out to be patches over the same shape of problem in a new place. We will know which as the next round of disclosures comes through, and the spec will move again.

For those of us building on MCP today, I do not think the right response is either alarm or complacency. It is, more or less, what one would want to bring to any protocol still finding its shape: use it where it earns its keep, keep half an eye on where the standard is changing and why, and remember that the cracks will tend to reappear in the same place. They will reappear, in my experience, wherever we are still designing — without quite noticing it — for a person who is no longer there.

This is the third in a series on the engineering reality of MCP. The first two (MCP vs Skills, Skills vs MCP Servers) argued about cost and security in tool choice. This one was always going to be the harder one — comments, corrections, and disclosure stories welcome.

Skills vs MCP Servers: The Hidden Cost of Tools in LLM Workflows

2026-06-07T00:00:00+02:00

When you start wiring a language model into real work, you quickly discover that the choice of how it reaches the outside world is not a detail. It is the single decision that drives token bills, latency, security posture, and — perhaps most underrated — how much configuration pain your team is signing up for.

Two approaches dominate today: MCP servers and skills. They look similar on the surface (both give the model "tools"), but they sit on opposite ends of almost every meaningful axis. Understanding where each one shines is the difference between an assistant that feels like a colleague and one that feels like a very expensive intern who keeps forgetting where the kitchen is.

The token tax of MCP

An MCP server is, at its core, a contract. It exposes a list of tools, and for each tool it must declare — upfront, at the start of every interaction — a precise description of what the tool does, the shape of its parameters, and the structure of the data it returns. This is what makes MCP feel so clean from a software-engineering perspective: it is strongly typed, self-documenting, schema-first.

But that beauty has a price, and the price is paid in tokens.

Every tool description, every parameter docstring, every return-type schema gets loaded into the context window the moment the conversation begins. The model has to "see" the whole catalogue before it can decide what to do — even if, in the end, it only uses one tool out of forty. And it pays that cost again on every turn, because the tool definitions live in the context.

Connect three or four MCP servers — say a Jira server, Slack , Github !!! — and you can easily burn ten or twenty thousand tokens before the user has even typed a question. That is not an exaggeration: it is the normal operating condition of a richly integrated MCP setup. And the configuration side is rarely ergonomic either: each server wants its own JSON block, its own credentials, its own lifecycle, its own quirks about transport and authentication.

Skills work the way developers actually work

A skill, by contrast, is closer to how a human engineer approaches an unfamiliar tool. You don't read the entire git manual before your first commit. You type git --help, then git commit --help when you need it, and you progressively build a working mental model of just the parts that matter for the job in front of you.

A well-designed skill encodes exactly that posture. It tells the model: here is a CLI, here is the entry point, here is the philosophy — explore it when you need it. The model then uses the existing command-line tool, discovers flags on demand, and only pays for the surface area it actually touches.

The implications are significant:

Tokens scale with the task, not with the catalogue. If the work needs three gh subcommands, you pay for three subcommands. The other 197 stay invisible.
The CLI already exists. No server to deploy, no schema to maintain, no transport to debug. You are reusing decades of Unix engineering.
Composition is free. Pipes, redirects, xargs, jq — the model inherits all of it. With MCP, every composition has to be modeled as a new tool or chained call.

The security angle nobody talks about

There is a second, quieter advantage of skills over MCP that I think deserves more attention: security.

When a skill drives a CLI, it inherits the security model of the host operating system. The command runs as the local user, with that user's permissions, against that user's keychain, SSH agent, ~/.aws/credentials, gcloud session, kubectl context — whatever credential machinery is already in place and already audited by your IT and your habits. There is no extra surface to attack, no new long-lived token to rotate, no new daemon to keep patched.

MCP servers, by their nature, want their own configuration. They often need their own copies of credentials, their own auth flows, their own way of holding state between calls. That is not inherently insecure — many MCP servers are written carefully — but it is additional surface area. Every new MCP server is a new place where a secret can leak, a permission can be misconfigured, or a vulnerability can hide. A skill that wraps aws or kubectl adds zero new credentials to your laptop. An MCP server for AWS adds at least one.

For teams that already have a mature CLI-based security story — and most engineering teams do, even if they don't think of it that way — skills give you tool access for free, on top of a model the security team has already reviewed.

A controversial case: connecting to MySQL

I want to be honest about where this argument breaks down, because it taught me something.

Recently I needed an assistant to work against a MySQL database. The "skill" route was obvious: just let it use the mysql CLI. It is well-known, secure, and uses the system's own credential files. Clean, ergonomic, almost no setup. I expected it to be the clear winner.

It wasn't. Or at least, not unambiguously.

The CLI approach turned out to be slow and token-hungry in a way I had not anticipated. Every query opened a new client session — connecting, authenticating, executing, tearing down. The result came back as raw text, which the model then had to re-parse on every step, often re-issuing similar queries just to confirm the shape of what it had already seen. For analytical work involving many sequential queries, this was painful.

The MySQL MCP server, on the other hand, kept a connection pool open. It pre-processed the result set into a structured form the model could consume without re-tokenising whole tables. It dramatically reduced the per-query overhead, both in latency and in tokens. For that specific workload — many small queries against the same database, in the same session — MCP was genuinely the better tool.

The lesson is not "MCP wins after all." The lesson is more interesting: MCP is worth its overhead when it provides something the CLI fundamentally cannot — persistent state, structured pre-processing, server-side intelligence. A mysql CLI invocation is stateless by design; it cannot pool connections or cache schema metadata across calls. The MCP server can. That capability gap, not the schema cleanliness, is what justifies the cost.

So the honest rule is: prefer skills by default, but reach for MCP when the integration needs state, pooling, binary assets, OAuth dances, or any other capability that a single CLI invocation genuinely cannot offer. Not because MCP is more modern, not because the schema is prettier — because the workload demands persistence the shell cannot give you.

Where MCP is the obvious answer: complex, non-textual systems

The MySQL story is the subtle case. There is also a much more obvious one, and it is worth naming explicitly: systems that simply do not live in text.

Think of Excalidraw, Canva, Figma, a 3D scene editor, a video timeline, a BI dashboard builder. These platforms are not just "an API with some commands" — they are spatial, visual, stateful environments. A shape on a canvas has coordinates, layers, z-order, parent groups, bindings to other shapes; a Canva design has templates, brand kits, asset libraries, page hierarchies. None of that maps cleanly to a stream of bytes flowing through a pipe.

For these systems, the CLI story falls apart for reasons no amount of cleverness can fix:

There is no good text representation. You cannot meaningfully describe "the element 40 pixels to the right of the title, snapped to the grid, grouped with the icon" in shell flags.
State is essential. The user (or the model) is working inside an open document, not invoking one-shot commands. Selection, focus, undo history, currently active tool — all of this is context that needs to live somewhere.
Binary and structured assets dominate. Images, fonts, embedded media, vector primitives. A CLI can shuffle files around; it cannot reason about a layout.
Round-trips need to be cheap. Adding a node, moving it, re-styling it, and reading back the result needs to feel like a conversation with the canvas, not a series of full re-renders.

An MCP server for Excalidraw or Canva is in its element precisely here. It can hold the document open, expose primitives that match the concepts of the tool (create node, connect nodes, set fill, group selection), and let the model think in the vocabulary of the platform instead of in the vocabulary of bash. The token cost of the schema, which felt extravagant for a database CLI, suddenly looks like a bargain when the alternative is "describe a whiteboard over stdout."

In other words: the more a system departs from the Unix philosophy of "everything is text," the more MCP earns its keep. For canvases, design tools, creative software, and rich SaaS environments with their own native object models, MCP is not a luxury — it is the only honest way to bridge model and tool.

The epic conclusion

There is a beautiful symmetry in all this. We spent decades building Unix into one of the most quietly powerful platforms in computing: composable, scriptable, securable, observable, and — crucially — cheap. Every command-line tool is a small, hard-won monument to clarity. Every credential file, every SSH key, every IAM role represents years of organisational learning about how to keep secrets in the right hands.

Skills let language models stand on that mountain.

They let the model behave like a thoughtful new hire who reads the help text, asks the system what it can do, and uses the credentials already sitting on the laptop — no new servers, no new secrets, no new schemas, no new tax on every token of context. They scale down to nothing when unused and up to everything when needed. They are, in the deepest sense, aligned with the grain of the system they run on.

MCP, in turn, becomes what it should always have been: not the default front door for every integration, but the specialist tool for the cases where text and shell are genuinely insufficient — when you need to render a slide, drive a design canvas, hold an OAuth session, pool a database connection, stream binary assets through a protocol the terminal was never meant to carry.

The choice is no longer "which protocol is more elegant." It is the older, harder, more interesting question that good engineering has always asked: what is the smallest, cheapest, safest thing that will actually do the job?

For most of what we ask language models to do every day, the answer was sitting in /usr/local/bin the whole time.

MCP vs Skills: when to use which in professional LLM-assisted coding

2026-05-10T22:48:00+02:00

Anyone who has spent years doing systems integration immediately understands the appeal of MCP. The dream in this field has always been the same: a clean contract between systems, where every method is described, every parameter is typed, every response is predictable. No more 80-page PDFs read half-heartedly, no more reverse engineering undocumented APIs, no more "ask Dave, he knows how it works." Just a schema, and everything else follows.

MCP delivers exactly that dream — but for language models. An MCP server exposes its tools with human-readable descriptions, structured parameters, defined types. The model reads the schema and already knows what it can do and how to do it. For anyone coming from systems integration, it's almost moving: it feels like someone finally applied the principles of good API design to the problem of making LLMs collaborate with the outside world.

The appeal is undeniable. And justified — MCP is genuinely a good idea, well executed.

But it's not a silver bullet. Like almost every elegant solution in software architecture, it comes with trade-offs that only become visible when you start using it in production, on real problems, with real constraints of cost and latency.

The problem nobody tells you about

When a team starts using LLMs seriously for coding, they inevitably reach a fork in the road: how do you make the model interact with the outside world? How do you give it access to the right tools without turning every request into an exercise in token waste?

Two dominant approaches exist: MCP servers (Model Context Protocol) and CLI-based skills. They are not equivalent. Choosing the wrong one has a real cost — in latency, inference costs, and maintenance complexity.

What they are, briefly

MCP is a standardized protocol that allows the model to interact with external services through a structured interface. The MCP server exposes tools, resources, and prompts that the model can invoke natively, with authentication and state managed server-side.

CLI-based skills are a more hands-on approach: you teach the model to use command-line tools by documenting how to invoke them, which flags they accept, what they return. The model learns to progressively "discover" the tool's capabilities, much like a developer consulting a man page for the first time.

When MCP is the right choice

MCP shines in one specific case: when you need to integrate complex external systems that don't naturally speak the language of text.

Think Canva. Or Figma. Or a BI system that generates interactive charts, a DAW for audio production, a 3D rendering platform. These systems have rich APIs, complex state management, OAuth authentication, webhooks, binary assets. They are not designed to be consumed or produced as text — they are designed to be used, with clicks, drags, graphical parameters, visual previews.

In these cases, an MCP server does excellent work:

Abstracts complexity: the model doesn't need to know how Canva's API works internally. It only knows that a create_presentation tool exists with certain parameters.
Manages state: authentication, session tokens, user context — everything lives in the MCP server, not in the prompt.
Is type-safe: MCP tools have defined schemas. The model receives structured feedback, not raw text to parse.
Is auditable: every tool call is loggable, traceable, revocable.

A concrete example: you want the model to automatically generate documentation slides from your code. With MCP you can integrate Canva or Google Slides directly, with access to company templates, brand fonts, layout systems — things that via CLI would be impossible or would require a massive wrapper.

When CLI Skills are superior

For everyday professional coding, CLI-based skills beat MCP on one fundamental point: token usage.

Consider what happens when you use an MCP server: at context initialization, the model must receive the full list of available tools, with their schemas, descriptions, and parameters. If the server exposes 40 tools (perfectly normal for an enterprise integration), you're burning hundreds or thousands of tokens before making a single useful request.

CLI skills work differently. They work the way an experienced developer works: in a progressive and contextual manner.

The model learns that a tool exists (say gh for GitHub CLI, or kubectl, or terraform). When it needs to do something, it can invoke gh --help or gh issue --help to discover exactly the flags it needs, at the moment it needs them. It doesn't hold everything in its head from the start — it discovers progressively.

This leads to concrete advantages:

Token efficiency: context grows only where needed. If the task is "create a PR with this diff", the model uses 3-4 commands. It doesn't load documentation for all 200 gh commands.

Unix composability: CLIs compose. git log --oneline | grep "fix" | head -20 is a powerful operation combining three tools. With MCP, the same result would require separate calls or a dedicated tool.

Natural debugging: when a command fails, the error output is text. The model reads it, understands, corrects. With MCP, errors pass through an extra layer of abstraction.

Zero infrastructure setup: a CLI skill is a text file documenting how to use an already-existing tool. An MCP server is a service to deploy, maintain, and monitor.

The progressive discovery pattern

This is the most underrated aspect of CLI skills, and it's worth dwelling on.

A developer who doesn't know a tool doesn't read the 300-page manual before starting. They type the command, read the help, try, fail, try again. The feedback loop is fast and contextual.

LLMs can do the same thing — and they should.

A well-written skill is not an encyclopedic dump of documentation. It's a starting point:

# terraform skill
Use `terraform` to manage infrastructure as code.
Entry point: `terraform --help` to discover subcommands.
Common pattern: init → plan → apply.
For details on a subcommand: `terraform <subcommand> --help`.

The model will start from this base and build understanding of the tool during execution, exactly like a junior developer in their first sprint with a new technology.

This directly contrasts with the MCP approach, where all tools must be declared upfront in the server schema — the model knows everything from the start, but pays for that "everything" in tokens on every call.

A practical decision matrix

Criterion	MCP	CLI Skill
Non-textual external system (graphics, audio, BI)	✓	✗
OAuth authentication / complex sessions	✓	Depends
Tools already available as CLI	✗	✓
Limited token budget	✗	✓
Small team, zero infrastructure to manage	✗	✓
Structured audit trail required	✓	Partial
Unix pipe composability	✗	✓
Enterprise SaaS system integration	✓	✗

The hybrid case: you don't have to choose

In a mature professional coding workflow, the right answer is often hybrid:

MCP for integrations with external systems that genuinely require it (the design system in Figma, notifications in Slack, deploys on platforms with complex APIs)
CLI skills for the entire development toolchain: git, Docker, kubectl, terraform, test runners, linters, package managers

The key point is not to use MCP out of laziness (because "it's more modern") or CLI skills out of frugality (because "it's simpler") — but to choose based on the nature of the system being integrated and the real token cost of each interaction.

MCP and CLI skills are not in competition — they solve different problems.

MCP is powerful when you need to bring the model into the territory of systems that don't speak text: graphical systems, creative platforms, SaaS services with complex state. It's the only sensible way to do things like "generate a Canva presentation from my README."

CLI skills are gold in everyday professional coding, where tools are already excellent, already composable, already battle-tested by decades of Unix philosophy — and where every unused token is money saved and latency reduced.

Progressive CLI discovery, moreover, is not a limitation: it's a feature. It teaches the model to reason like a good developer — starting from the bare minimum and building understanding only where needed.

Running Gemma 4 31B on an Apple Silicon Mac with Ollama

2026-04-26T22:48:00+02:00

A practical configuration for a 32 GB M5 Mac that still needs to remain usable

Running large language models locally has become surprisingly practical on Apple Silicon. With a modern Mac, Ollama, and a carefully quantized GGUF model, it is possible to run models that only a short time ago would have felt out of reach for a personal machine.

This post collects the practical findings from configuring Gemma 4 31B on a 32 GB Apple Silicon Mac with an M5 processor, using Ollama and a highly compressed GGUF quantization.

The goal is not to squeeze every last token per second out of the machine. The goal is more realistic:

Run a capable 31B local model while keeping the Mac usable for normal work: browser, IDE, terminal, notes, chat apps, and light development tools.

That distinction matters. A configuration that works for a benchmark is not necessarily a configuration you want to live with all day.

The model

The model used in this setup is:

gemma-4-31B-it-UD-IQ3_XXS.gguf

This is an aggressively quantized GGUF build of Gemma 4 31B. The IQ3_XXS quantization makes the model small enough to fit into machines that would otherwise be unable to run a 31B model at all.

The trade-off is obvious: this is not the highest quality quantization, but it gives access to a much larger model class on consumer hardware.

The Ollama Modelfile starts from the local GGUF file:

FROM ./gemma-4-31B-it-UD-IQ3_XXS.gguf

Understanding the main Ollama parameters

Before tuning the configuration, it helps to understand what the key parameters actually control.

`num_ctx`

num_ctx controls the maximum context window used by the model.

A larger context means the model can keep more conversation, documents, code, or instructions in memory. But it also increases memory usage, especially through the KV cache.

For this model, useful values are:

6144   conservative
8192   balanced
12288  aggressive

For daily use on a 32 GB Mac, 8192 is a good target.

`num_batch`

num_batch affects how many tokens are processed together during prompt ingestion.

It mostly impacts the speed at which the model reads the input prompt, not necessarily the speed at which it generates the answer token by token.

Higher values can improve responsiveness with longer prompts, but they also increase temporary memory pressure.

Good values for this setup are:

32   conservative
64   balanced
96   aggressive

For a daily driver configuration, 64 is a reasonable compromise. If the Mac becomes sluggish or the runner crashes, this is one of the first values to reduce.

`num_gpu`

In Ollama, num_gpu does not mean “number of GPUs”. It means how many model layers are offloaded to the GPU.

For Gemma 4 31B, the theoretical maximum is:

num_gpu 60

because the model has 60 layers.

However, full offload is not always the best practical choice. On a machine that must remain usable for other work, leaving some margin is often better than maximizing GPU offload.

For a 32 GB M5 Mac, a good range is:

50   conservative
55   balanced
60   aggressive / full offload

The recommended daily value is 55.

The recommended daily configuration

This is the configuration I would use as a balanced daily driver.

It gives a useful context window, keeps prompt processing reasonably fast, and avoids pushing the system too close to the edge.

FROM ./gemma-4-31B-it-UD-IQ3_XXS.gguf

PARAMETER num_ctx 8192
PARAMETER num_batch 64
PARAMETER num_gpu 55

PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64

Create or replace the model with:

cd ~/ollama-models/gemma4-31b-iq3

cat > Modelfile <<'EOF'
FROM ./gemma-4-31B-it-UD-IQ3_XXS.gguf

PARAMETER num_ctx 8192
PARAMETER num_batch 64
PARAMETER num_gpu 55

PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64
EOF

ollama stop gemma4-31b-iq3xxs-32gb
ollama rm gemma4-31b-iq3xxs-32gb
ollama create gemma4-31b-iq3xxs-32gb -f ./Modelfile

Then test it:

ollama run gemma4-31b-iq3xxs-32gb "Write a Python hello world."

Environment variables

For this setup, Flash Attention and quantized KV cache are useful.

If using the Ollama macOS app, set the variables with launchctl:

launchctl setenv OLLAMA_FLASH_ATTENTION "1"
launchctl setenv OLLAMA_KV_CACHE_TYPE "q8_0"
launchctl setenv OLLAMA_CONTEXT_LENGTH "8192"
launchctl setenv OLLAMA_KEEP_ALIVE "5m"

Then quit and reopen Ollama from the menu bar.

If running Ollama manually from the terminal:

OLLAMA_FLASH_ATTENTION=1 \
OLLAMA_KV_CACHE_TYPE=q8_0 \
OLLAMA_CONTEXT_LENGTH=8192 \
OLLAMA_KEEP_ALIVE=5m \
ollama serve

What `OLLAMA_KV_CACHE_TYPE=q8_0` does

The KV cache stores the internal attention state for tokens that have already been processed. It grows with the active context length.

Using:

OLLAMA_KV_CACHE_TYPE=q8_0

asks Ollama to store the KV cache in an 8-bit quantized format.

The practical effect is:

lower memory usage
better support for longer context windows
usually minimal quality loss compared to f16 KV cache

It is especially useful when running large models with larger context windows.

However, it does not significantly reduce the memory used by the model weights themselves. It mainly helps with memory used by context.

For this reason, q8_0 is useful, but it is not a magic fix for every memory issue.

Flash Attention

Flash Attention should be enabled when using quantized KV cache:

OLLAMA_FLASH_ATTENTION=1

It helps reduce memory usage and can improve efficiency with larger contexts.

For this model, I would keep it enabled.

Keeping the Mac usable

Apple Silicon uses unified memory. The CPU and GPU share the same memory pool.

That means a local LLM can directly compete with everything else on the Mac:

browser tabs
IDE
Docker
database containers
video calls
Slack or Teams
file indexing
other development tools

This is why the best configuration is not necessarily the most aggressive one.

The aim is to leave enough headroom that the system does not constantly swap or become unresponsive.

Wired memory limit

Some users increase the Metal wired memory limit with:

sudo sysctl iogpu.wired_limit_mb=22000

On a 32 GB Mac, I would use one of these values:

20000  conservative workstation mode
22000  balanced daily mode
24000  LLM-priority mode

For daily work, I would start with:

sudo sysctl iogpu.wired_limit_mb=22000

I would avoid pushing this too close to total system memory. Values like 28000 or 30000 may help a benchmark but can make the machine unpleasant to use for normal work.

Three practical profiles

1. Workstation profile

Use this when you also need Docker, an IDE, many browser tabs, or other heavy tools.

FROM ./gemma-4-31B-it-UD-IQ3_XXS.gguf

PARAMETER num_ctx 6144
PARAMETER num_batch 32
PARAMETER num_gpu 50

PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64

Recommended environment:

sudo sysctl iogpu.wired_limit_mb=20000

launchctl setenv OLLAMA_FLASH_ATTENTION "1"
launchctl setenv OLLAMA_KV_CACHE_TYPE "q8_0"
launchctl setenv OLLAMA_CONTEXT_LENGTH "6144"
launchctl setenv OLLAMA_KEEP_ALIVE "2m"

This is the safest profile for a Mac that must remain responsive.

2. Balanced daily profile

This is the recommended default.

FROM ./gemma-4-31B-it-UD-IQ3_XXS.gguf

PARAMETER num_ctx 8192
PARAMETER num_batch 64
PARAMETER num_gpu 55

PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64

Recommended environment:

sudo sysctl iogpu.wired_limit_mb=22000

launchctl setenv OLLAMA_FLASH_ATTENTION "1"
launchctl setenv OLLAMA_KV_CACHE_TYPE "q8_0"
launchctl setenv OLLAMA_CONTEXT_LENGTH "8192"
launchctl setenv OLLAMA_KEEP_ALIVE "5m"

This is the profile I would use most of the time.

3. LLM-priority profile

Use this when the Mac is mostly dedicated to local inference.

FROM ./gemma-4-31B-it-UD-IQ3_XXS.gguf

PARAMETER num_ctx 12288
PARAMETER num_batch 96
PARAMETER num_gpu 60

PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64

Recommended environment:

sudo sysctl iogpu.wired_limit_mb=24000

launchctl setenv OLLAMA_FLASH_ATTENTION "1"
launchctl setenv OLLAMA_KV_CACHE_TYPE "q8_0"
launchctl setenv OLLAMA_CONTEXT_LENGTH "12288"
launchctl setenv OLLAMA_KEEP_ALIVE "10m"

This is more aggressive. It may be useful for focused LLM sessions, but I would not use it while doing normal development work.

How to verify what is happening

After running the model, check:

ollama ps

This shows whether the model is loaded and how it is using the available processors.

To inspect logs:

grep -iE "offload|layers|gpu|metal|memory" ~/.ollama/logs/server.log | tail -n 80

Look for messages indicating how many layers were offloaded to the GPU.

For example:

offloaded 55/60 layers to GPU

That confirms that num_gpu 55 is actually being applied.

Troubleshooting instability

If Ollama crashes or the Mac becomes sluggish, reduce parameters in this order.

First reduce num_batch:

64 -> 32

Then reduce num_ctx:

8192 -> 6144

Then reduce num_gpu:

55 -> 50

Finally reduce the wired memory limit:

22000 -> 20000

A stable machine is more useful than a theoretical maximum configuration that crashes during real work.

About Metal crashes

During experimentation, one possible failure mode is a Metal backend crash, with logs similar to:

ggml-metal-device.m:608: GGML_ASSERT([rsets->data count] == 0) failed
panic during panic

When this happens, it is often better to reset the setup rather than keep pushing the same configuration.

A practical recovery sequence is:

killall Ollama
killall ollama

launchctl unsetenv OLLAMA_FLASH_ATTENTION
launchctl unsetenv OLLAMA_KV_CACHE_TYPE
launchctl unsetenv OLLAMA_CONTEXT_LENGTH

sudo sysctl iogpu.wired_limit_mb=20000

Then reboot the Mac and restart from a conservative profile.

Final recommendation

For a 32 GB M5 Mac that should remain useful as a normal workstation, I would use this:

sudo sysctl iogpu.wired_limit_mb=22000

launchctl setenv OLLAMA_FLASH_ATTENTION "1"
launchctl setenv OLLAMA_KV_CACHE_TYPE "q8_0"
launchctl setenv OLLAMA_CONTEXT_LENGTH "8192"
launchctl setenv OLLAMA_KEEP_ALIVE "5m"

And this Modelfile:

FROM ./gemma-4-31B-it-UD-IQ3_XXS.gguf

PARAMETER num_ctx 8192
PARAMETER num_batch 64
PARAMETER num_gpu 55

PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER top_k 64

This is not the most extreme configuration. It is the one I would actually want to use.

It gives enough context for serious work, enough GPU offload for acceptable performance, and enough memory headroom to keep the Mac usable while doing other things.

That is usually the sweet spot for local LLMs: not maximum throughput, but sustainable performance.

Giving voice to Italian energy markets with artificial intelligence

2026-04-12T22:48:00+02:00

How an MCP server turns electricity exchange data into natural conversations

The Italian electricity market produces an enormous amount of data every day: hourly prices by zone, traded volumes, liquidity, the PUN (Prezzo Unico Nazionale — the national single price). Essential data for traders, energy analysts, industry journalists, and companies operating in the energy sector. Yet accessing this data still means navigating web portals, downloading CSVs, and writing ad-hoc scripts. A fragmented and slow workflow.

With mercati-energetici-mcp I set out to change the approach: making GME (Gestore dei Mercati Energetici — the Italian Energy Markets Operator) data directly accessible from within the AI assistants we already use every day — Claude, Copilot, and any other tool compatible with the MCP protocol.

What is MCP and why it changes the game

The Model Context Protocol is an open standard that allows language models to interact with external services in a structured way. Think of it as a bridge: on one side there's the AI that knows how to reason, on the other there's real-world data. MCP connects them.

Before MCP, getting an LLM to access market data required building custom integrations, prompt engineering pipelines, or manually copying and pasting data into the conversation context. With MCP, you simply declare tools — functions the AI can invoke autonomously whenever it needs them.

The difference is substantial: you no longer have to retrieve the data yourself and then ask the AI to analyze it. The AI itself, during the conversation, decides when and which data it needs and retrieves it on its own.

The implementation: Python, FastMCP, and simplicity

The project is intentionally minimal. A single Python file, about 150 lines of code, exposing 5 tools:

get_prices — hourly energy prices by zone and day
get_volumes — bought and sold volumes on the market
get_liquidity — hourly market liquidity percentage
daily_pun — daily national average price
get_zones — list of available market zones

The mercati-energetici library handles the interaction with the official GME APIs. FastMCP manages the entire MCP protocol, turning simple Python functions decorated with @server.tool() into endpoints that any MCP client can discover and invoke.

The code for a tool is disarmingly simple:

@server.tool()
async def get_prices(day: Optional[str] = None, zone: str = "PUN") -> str:
    """Get electricity prices in €/MWh for a specific day and zone."""
    async with init_MGP() as mgp:
        result = await mgp.get_prices(day=day, zone=zone)
        return json.dumps({"prices": result, "unit": "€/MWh", "zone": zone})

No boilerplate, no complex configuration. The docstring automatically becomes the description the AI reads to understand when and how to use the tool. The type hints on parameters become the JSON schema that the protocol uses for validation.

Integration with Claude and Copilot

Claude Desktop and Claude Code

Once the server is configured in Claude's config, electricity market data becomes a natural part of the conversation. You can ask:

"What was the price of energy in Sicily yesterday?"

Claude doesn't search the internet, doesn't hallucinate a number: it invokes get_prices with the correct parameters and returns the actual data from GME. You can go further:

"Compare today's prices between Northern and Southern Italy and tell me if there's a significant gradient"

The AI calls the tool twice, once per zone, and then reasons on the real data to produce an analysis.

"Show me the PUN trend over the last week and identify any anomalies"

Here Claude chains multiple calls to daily_pun for different days, builds a time series, and applies its analytical reasoning on concrete data.

GitHub Copilot

With MCP support expanding across the Copilot ecosystem as well, the same server can power energy analyses directly within the IDE. A data analyst writing Python code for a report can have market data at prompt's reach, without leaving VS Code.

Any MCP client

The beauty of an open standard is that you're not locked into a vendor. Any tool that speaks MCP — present or future — can connect to this server and access Italian electricity market data.

Concrete use cases

For the energy trader: quick analysis of zonal prices, cross-zone comparison, pattern identification in traded volumes. All in natural language, without having to open spreadsheets.

For the industry analyst: automatic generation of daily or weekly reports on the electricity market, with AI-produced commentary and interpretations based on real data.

For the journalist: immediate access to market data for articles and in-depth pieces, with the ability to ask the AI for explanations and context.

For the developer: a concrete example of how to build an MCP server for a vertical domain, reusable as a template for other markets or data sources.

For the energy company: integration of exchange data into internal workflows, from customer service answering pricing questions to the procurement office monitoring the market.

The value of the MCP approach

The real innovation isn't in the code — it's in the paradigm. We're moving from a model where the user is the intermediary between data and AI, to one where the AI accesses data directly and uses it within the conversation context.

This means:

No more copy-paste: data flows directly into the AI's reasoning
Always up-to-date data: every request queries the GME APIs in real time
Contextual analysis: the AI can combine data from multiple calls to produce insights that would otherwise require manual work
Accessibility: anyone can query the electricity market in natural language, without specific technical skills

Getting started

The project is open source under the MIT license. To try it you need:

Python 3.12+ and uv as a package manager
A GME account with API access (request it at mercatoelettrico.org)
An MCP client — Claude Desktop, Claude Code, or any other compatible one

git clone https://github.com/sammyrulez/mercati-energetici-mcp
cd mercati-energetici-mcp
uv sync

Configure your credentials and you're up and running. Less than 5 minutes from installation to your first natural language query about energy prices.

Conclusion

The Italian electricity market is a data-rich domain but historically not very accessible. With an MCP server of just a few lines of code, this data becomes an integral part of AI conversations — transforming a fragmented workflow into a fluid and natural dialogue.

It's a small project, but it represents a powerful pattern: any structured data source can become an MCP tool, and therefore become accessible through natural language. Energy markets are just the beginning.

Stop Putting Secrets in Your Repo. Seriously.

2026-03-27T22:48:00+01:00

OK. We've all been there. You're setting up a new microservice, you need a database connection string, a Keycloak client secret, an OCIR auth token — and before you know it, you're copy-pasting credentials into a .tfvars file and telling yourself "I'll fix this later".

Later never comes. Until it does, and it's painful.

This post walks through how we wired up OCI Vault with Terraform to manage secrets properly — and why the side effects are even better than the main benefit.

The Problem with `TF_VAR_` and Plain tfvars

The classic approach for passing secrets to Terraform is either:

export TF_VAR_my_secret="..." before every apply
A secrets.tfvars file conveniently added to .gitignore (and inevitably forgotten on a new machine)

Both approaches work until they don't:

A new team member clones the repo and has no idea what secrets to set
CI/CD needs the secret injected as a pipeline variable — now you're duplicating it
Someone accidentally commits the file. It happens.
You rotate a credential and have to remember every place it's used

The real issue is that secrets live outside your infrastructure definition. They're implicit, undocumented, and fragile.

Enter OCI Vault

OCI Vault is Oracle Cloud's managed secret store. Think of it as a safe deposit box that Terraform can open at plan/apply time. You store the secret once, reference it by OCID, and Terraform fetches the value directly — no environment variables, no hidden files.

Creating a secret

oci vault secret create-base64 \
  --compartment-id $COMPARTMENT_ID \
  --vault-id $VAULT_OCID \
  --key-id $KEY_OCID \
  --secret-name "my-service-db-password" \
  --secret-content-content "$(echo -n 'supersecret' | base64)"

That's it. The secret now has an OCID you can reference anywhere.

Wiring It Into Terraform

The integration is clean. Declare a data source, decode the content, use it where you need it:

data "oci_secrets_secretbundle" "db_password" {
  secret_id = var.db_password_secret_ocid
}

module "microservice" {
  ...
  app_secrets = {
    Oracle__ConnectionString = base64decode(
      data.oci_secrets_secretbundle.db_password.secret_bundle_content[0].content
    )
  }
}

Your common.tfvars now contains only an OCID — a pointer, not a value:

db_password_secret_ocid = "ocid1.vaultsecret.oc1.eu-miami-1.amaaaaaaxxx"

An OCID is not a secret. You can commit it. You can share it. You can put it in a ticket. The actual value stays in the Vault, protected by IAM policies and audit logs.

The Real Win: A Repo You Can Actually Share

Here's the part that doesn't get enough attention.

When your secrets live in a Vault and your repo contains only OCIDs and config, your entire infrastructure definition becomes fully committable. No .gitignore exceptions. No "ask a colleague for the secrets file". No onboarding friction.

A developer cloning the repo for the first time gets everything they need to understand the infrastructure — and with the right IAM permissions, they can run terraform plan immediately.

This changes the dynamic of your infrastructure code from "mostly version controlled" to "fully version controlled". And that matters more than it sounds:

Pull requests for infrastructure changes are complete — reviewers see the full picture, not just the non-sensitive half
Git history is trustworthy — a git log on main.tf tells the real story of what changed and when
Rollbacks are safe — checking out a previous commit gives you a working state, not a broken one missing secret references

Portability Across Environments and Teams

With this setup, spinning up a new environment is a two-step operation:

Create the secrets in the Vault for the new environment
Add the OCIDs to the new envs/staging.tfvars

No secret synchronization. No "which version of the connection string does staging use?". The Vault is the source of truth, and Terraform reads from it at apply time.

The same applies when onboarding a new microservice. Copy the infra_template/ directory, fill in the placeholders, point to the right Vault OCIDs — done. The template is self-documenting because there's nothing hidden.

Secret Rotation Without Drama

Rotating a secret used to mean: update the value in five places, hope you didn't miss one, redeploy everything, debug the one service that broke because you forgot to update its CI variable.

With Vault:

oci vault secret update-base64 \
  --secret-id $SECRET_OCID \
  --secret-content-content "$(echo -n 'new-value' | base64)"

Then terraform apply. Terraform fetches the new value, updates the Kubernetes secret, and the pod picks it up. One place, one command, full audit trail.

A Note on the Audit Trail

Every access to a Vault secret is logged in OCI Audit. You know who read what and when. This is not just a compliance checkbox — it's genuinely useful when you're debugging a production incident and need to know whether a secret was accessed or rotated in the last 24 hours.

Summary

Before	After
Secrets in `.tfvars`, gitignored	Only OCIDs in tfvars, fully committed
`export TF_VAR_secret=...` before every apply	No environment variables needed
Manual secret rotation in multiple places	One update in Vault, one `terraform apply`
Onboarding requires sharing secret files	Clone repo, get IAM access, run plan
Partial git history	Complete, trustworthy git history

The Vault setup takes an afternoon. The benefits compound forever. It's one of those infrastructure investments that quietly pays off every single day — even when nothing goes wrong.

Especially when nothing goes wrong.

Forecasting Time Series from a COVID-19 Red Zone

2020-04-17T22:48:00+02:00

Hello, dear citizen of the free world. I’m writing while I’m in a restricted lifestyle. On Monday night Italy’s prime minister decided that the entire country would be covered by restrictions that can be summarised as follows:

“I stay at home”

All travel was banned unless justified on professional or health grounds. You can go out to buy food and medications and nothing else. You can’t visit your parents if they are in a different neighborhood. I’m working remotely 100% of the time and trying to survive with two kids with a lot of spare time 😰.

The situation is serious just because the health care system is at its maximum capacity and lives of the elderly and other people with serious chronic afflictions are at stake. That said everything is fine: we have food and the sun shines as always in Italy.

So since I was already playing around with the Facebook Prophet library, I’m trying to put something together.

The government has been so efficient, beyond any expectation, to set up a Github repo with all the data cand even to update them daily!

I focus my effort on my province since there is less noise (regional and countrywide data could be misleading because the lockdown happened in different moments) and we are near the initial outbreak. And also I live here!

Disclaimer: This is more an exercise in building a time series pipeline rather than find significant data on when exactly this situation will end. I’m no epidemiologist. There are specific models for that and I’m purposely using one from a social network.

So the situation seems to flat out after 22 / 25 days.

So I clean up the data with pandas, filtered just the rows about my province and shape them to suit Prophet requirements

 bs= df.loc[df['sigla_provincia'] == 'BS']
    bs = bs.sort_values(by=['data'])
    bs = bs.drop(['stato', 'codice_regione', 'denominazione_regione','codice_provincia','sigla_provincia','lat','long','denominazione_provincia'], axis=1)
    bs = bs.reset_index(drop=True)
    bs.columns = ['ds','y']

Then I run 50 days forecast on this data.

    m = Prophet()
    m.fit(df)
    future = m.make_future_dataframe(periods=50)
    forecast = m.predict(future)

image

That is suspicious: we had more cases than in China. I have more confidence with the Italian data, but since the curve is monotonously increasing the prediction will just follow. In the hope to make some sense in this forecast, I added a regressor that made some sense: the number of days since the lockdown in Italy. Sadly is the same day that the data started to be recorded so it does not add much information. So I added two seasonalities to model the expected peak after 25 days after the first case and another after 14 days when new infections are less than the healed ones.

        m = Prophet()
        m.add_regressor('peak_reg')
        m.add_seasonality('peak_period_start',period=22,fourier_order=1)
        m.add_seasonality('peak_period_end',period=36,fourier_order=1)
        m.fit(df)
        future = m.make_future_dataframe(periods=28)
        future['ds_ts'] = pd.to_datetime(future['ds'])
        future['no_school'] = pd.Timestamp(datetime(2020,2,24))
        future['since_no_school'] = future['ds_ts'].sub(future['no_school'], axis=0).dt.days
        future['peak_reg'] =  future['since_no_school'].apply(peak_days )
        forecast = m.predict(future)

[image](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*uGUU8V4cwMeSz2IFWlr4yA.png)

The result is probably overfitting the burst we have in the last few days and the data set is so small. So the 8K infected predicted before the peak is an exaggerated estimation. But the dates of the estimated time of peak are the same as the epidemiologist model! I’m going to build a pipeline to run the model every day with new data and enhance the model estimations. Worst case scenario: the second day that the prediction is higher than the actual value the peak ha been reached and I learned something about Facebook Prophet. Best case scenario: I can predict the end of the lockdown and go back to the office.

I will ride like a gentlemen

2017-04-17T22:48:00+02:00

I will ride like a gentlemen

On September 24th I will ride in the Distinguished Gentlemen Ride

This is me an my bike at a recent Ducati Scrambler event

As a rider of a stylish Ducati Scrambler, I will join my local chapter of the DGR. It is a retro-themed motorbike event, held globally in the world, to raise funds for research into prostate cancer and mental health programs as part of our mission to support men’s health globally. These funds are invested by our partners the Movember Foundation, the world’s largest men’s health organization.

PROSTATE CANCER

Prostate cancer is the second most commonly diagnosed cancer in men. The Movember Foundation is the largest funder of prostate cancer programs in the world.

SUICIDE PREVENTION | MEN’S MENTAL HEALTH

3 out of 4 suicides are men

510,000 men die from suicide globally each year. That’s one every minute. This has to change.

This is my donation page. Every amount is Wellcome and will help someone in need. Thank You. Sam Reghenzi This year I am taking part in The Distinguished Gentleman's Ride to raise funds and awareness for mens health and…www.gentlemansride.com

UPDATE: this is the video of my ride: enjoy!

Sam Reghenzi Homepage

The Ontology Was Always a Bounded Context

The problem is real and it's measurable

The diagnosis that keeps being wrong

DDD already named this problem

Event-driven architecture already named the other half

Explicit structure isn't a compromise, it's a multiplier

Who maintains it: the review loop, not the curator

The provocation

The Guardrail Is Not in the Model

The failure that isn't a hallucination

The loop is where the power and the risk both come from

What an ontology is, in practical terms

This has been tried before

Where it goes in the loop

What this does not fix

The Baseline That Refuses to Die

What actually changed

The comparison nobody runs

A protocol worth actually running

Time series is a genuinely different story

The constraint nobody budgeted for

So: what do you actually do

Sources

Hardware Ate Software. But the Survivors Become Agents

What the article gets right

Capital intensity is not value capture

The layer the thesis forgot

Where gravity actually climbs

The engineer's version of the thesis

The interface inverts

Features stop being screens and become tools

What you actually invest in

The product is the job

What this looks like in the wild

The prognosis, flipped

OAuth's Original Sin: Why MCP Inherited a Problem Designed for Humans

The protocol that assumed a human

What MCP inherited

The cracks: four assumptions that break

Zoom-in 1: anatomy of a real one-click takeover

Zoom-in 2: the DCR dilemma

What's still open

Skills vs MCP Servers: The Hidden Cost of Tools in LLM Workflows

The token tax of MCP

Skills work the way developers actually work

The security angle nobody talks about

A controversial case: connecting to MySQL

Where MCP is the obvious answer: complex, non-textual systems

The epic conclusion

MCP vs Skills: when to use which in professional LLM-assisted coding

The problem nobody tells you about

What they are, briefly

When MCP is the right choice

When CLI Skills are superior

The progressive discovery pattern

A practical decision matrix

The hybrid case: you don't have to choose

Running Gemma 4 31B on an Apple Silicon Mac with Ollama

A practical configuration for a 32 GB M5 Mac that still needs to remain usable

The model

Understanding the main Ollama parameters

num_ctx

num_batch

num_gpu

The recommended daily configuration

Environment variables

What OLLAMA_KV_CACHE_TYPE=q8_0 does

Flash Attention

Keeping the Mac usable

Wired memory limit

Three practical profiles

1. Workstation profile

2. Balanced daily profile

3. LLM-priority profile

How to verify what is happening

Troubleshooting instability

About Metal crashes

Final recommendation

Giving voice to Italian energy markets with artificial intelligence

`num_ctx`

`num_batch`

`num_gpu`

What `OLLAMA_KV_CACHE_TYPE=q8_0` does

The Problem with `TF_VAR_` and Plain tfvars