DEV Community: Nasiko Labs

Your coding agent plan is a subsidy

Shrawan Saproo — Sun, 11 Oct 2026 15:59:02 +0000

The monthly fee tells you what access costs. It doesn’t tell you what your work consumes.

At Nasiko, we’re building around a question every team using agents should be able to answer: what did this work consume, and what did it accomplish? Coding subscriptions can make that connection easy to overlook. The monthly fee is predictable, even when the work behind it changes.

You’re halfway through fixing a bug with your coding agent when you hit the usage limit. It’s made a few changes, but the tests still fail. You’ll have to wait for the reset to continue.

You know there’s work left, but it’s harder to tell what used up the allowance. The agent spent time reading the codebase, running tests, and trying fixes. The conversation got longer as it went. Without a breakdown, you’re left guessing which of those contributed most.

The monthly bill doesn’t help. It’s the same amount you paid last month, regardless of how the work went.

That predictability makes experimentation easier. We can explore an unfamiliar codebase without pricing every question. But it also separates the work from its consumption.

A subscription prices access under a particular set of rules. It does not tell us what the same work will cost under a different billing arrangement.

To understand that exposure, we need to connect consumption to the tasks that caused it. That connection matters while we are waiting for a reset. It matters more when we deploy the workflow, expand its use, or have to explain its budget.

In June 2026, SemiAnalysis bought subscriptions across OpenAI and Anthropic’s plan tiers and ran long coding tasks until they exhausted their weekly limits. It estimated maximum monthly API-equivalent usage of roughly $14,000 for the $200 ChatGPT tier and $8,000 for the $200 Claude tier. SemiAnalysis’s methodology and reported results.

Those figures describe consumption valued at API retail prices. They are not vendor costs.

SemiAnalysis modeled subscription gross margins assuming a 75% API gross margin. Its published break-even thresholds were approximately 5.7% utilization for the top OpenAI tier and 10% for the top Anthropic tier. Those thresholds concern modeled subscription gross margin, not either company’s overall profitability. Reported margin estimates.

The arithmetic reproduces the thresholds: at that assumption, $14,000 in API-priced consumption implies $3,500 in serving costs, and $200 divided by $3,500 is about 5.7%. The Claude example implies $2,000 in serving costs and a 10% threshold.

These are stress-test estimates under a stated margin assumption, not typical customer bills or guaranteed allowances. Their usefulness is the distance they expose between the subscription price and the economics of metered access.

For a team making a budget, that distance is a question to investigate. Our own workload might sit well below those extremes. It might also change substantially once a successful experiment becomes something we run every day.

Caching explains why the comparison needs care.

A coding agent repeatedly sends overlapping context: instructions, tool definitions, repository content, and conversation history. Prompt caching lets the provider reuse processing of matching prefixes.

Requesty’s analysis of production gateway traffic reported a 92% input-token cache hit rate for Claude Code in April 2026. That observation belongs to its dataset, but the consequence is clear: much of the input in those workloads was reused context, making the raw token count a poor guide to processing cost. Requesty’s research.

A subscription can therefore look generous partly because the workload is efficient to serve. Under the subscription, included cache reads do not create separate charges on our bill. Under API pricing, reads are discounted but still metered, while cache writes, new input, and output are billed at their own rates. Anthropic’s caching documentation.

A useful comparison preserves those categories. Pricing every token as uncached input inflates the estimate. Treating every cached token as free understates it.

Heavy interactive users can still get excellent value from subscriptions. Caching can also keep an API workload affordable. The efficiency may survive a move; the subscription entitlement depends on the destination's rules.

We encounter that boundary in ordinary engineering work.

An experiment becomes a service. Instead of supervising each run, we schedule the agent to process a queue. Jobs overlap, retries accumulate, and sessions begin with different context.

A team standardizes its tooling. Its enterprise agreement has different allowances or metering from the individual plans developers used during evaluation.

Or a provider changes what access includes.

Anthropic’s proposed Agent SDK billing split shows how unsettled these boundaries remain. The company announced a separate credit arrangement for SDK and claude -p usage, then paused it on June 15. Its current notice states that the affected usage continues to draw from subscription limits and that the announced separate credit is unavailable. The proposed split should not be treated as an implemented change. Anthropic’s current notice.

GitHub provides an implemented example. Usage-based AI Credits billing went live on June 1, with included allowances and controls for additional spending. Organizations can cap spending. GitHub’s release announcement.

The transition included temporary monthly allowances of $30 for Business and $70 for Enterprise during June, July, and August, compared with the announced standard allowances of $19 and $39. With that promotional period over, teams need to distinguish changes in consumption from changes in what their plan covers. GitHub’s billing announcement.

We do not need a prediction about the end of subscriptions. We already have a practical reason to understand our workloads independently of them.

The organizational consequences extend beyond the invoice.

In May, Windows Central, citing The Verge, reported that Microsoft’s Experiences + Devices division was expected to move from Claude Code to GitHub Copilot CLI by the end of June. The reporting described financial considerations alongside Microsoft’s interest in shaping its own tooling around internal repositories, security requirements, and workflows. Windows Central’s report.

That example shows how developer preference sits alongside budget, integration, and governance in tool selection. But the same problem appears in much smaller teams.

Imagine a team introducing automated pull-request reviews. Spending rises. The lead can see usage by developer, but cannot tell whether the increase came from broader review coverage, repeated attempts on the same failing job, or longer context carried into every request.

A blanket cap would control the total while leaving those questions unanswered. It might interrupt useful reviews and preserve the wasteful ones. Before changing the budget, the team needs to identify what the additional consumption accomplished.

That makes attribution as much an engineering concern as a finance concern.
A billing export can identify spending by account, project, key, and sometimes user or model. Those dimensions help allocate expenses. Explaining them requires execution context.

A shared key might serve a migration assistant, an incident investigation, and a nightly review job. A personal key might span several repositories. A single session might contain productive work followed by a long, unsuccessful detour.

The unit we pay for and the unit we make decisions about are different. Providers meter requests and tokens. Engineering teams decide whether a migration, investigation, or review was worth doing.

Consider a retry loop. The provider can accurately report the tokens consumed for each attempt. Execution context reveals that the attempts belonged to the same unresolved task. A task identifier, linked requests, and completion status let us distinguish an expensive success from an expensive failure.

Tool calls require similar care. A local test command may not have a model charge itself, but its output increases the charge of the next model request. Recording the sequence helps explain the cost without pretending that every tool invocation has an independently measurable token bill.

Existing telemetry supplies some of this evidence. Claude Code supports OpenTelemetry exports for usage, costs, tool activity, and sessions. The work is to collect it consistently and connect it to the repositories, tasks, owners, and outcomes our organization understands. Claude Code’s monitoring documentation.

That gives us a more productive conversation with decision-makers. We can show which workflows consumed more, whether they completed successfully, and where people still had to intervene. We can investigate repeated failures without treating heavy usage as evidence of poor judgment.

Token counts alone cannot establish value. An expensive session that resolves a production incident may be worth far more than dozens of inexpensive sessions whose changes are discarded. Measurement makes that tradeoff visible. It does not make the judgment for us.

We can begin with three concrete steps this week.

Price our own last week at published API rates. Export the available usage records. Separate uncached input, cache writes, cache reads, and output by model, then apply the corresponding rates. Label the result “API-equivalent estimate” and keep actual subscription payments alongside it. If records are incomplete, identify the gap and start collecting them now.
Connect consumption to sessions and tasks. Record session and request identifiers, repository, task, model, token categories, retries, and tool events. Preserve parent-child relationships when agents delegate work. Start with one workflow and verify that a costly run can be traced back to something an engineer recognizes. Reconcile the records against provider totals before using them for budget decisions.
Price the path out of the current plan. Identify which workflows would require API billing under their intended deployment. Estimate costs using observed cache behavior, expected volume, concurrency, and retries. Pair the estimate with an outcome measure, such as accepted changes or incidents resolved. That gives us a basis for deciding what is worth funding when the billing arrangement changes.

We built Nasiko to bring agent execution and consumption into the same view, so teams can investigate the runs behind their spending. Our open-source platform records execution traces and collects token usage and costs from telemetry, with session reporting for supported coding agents. The Nasiko repository includes the telemetry setup and a Docker quickstart that gets the platform running in minutes once prerequisites are in place.

The next time a session stops at a reset window, we may still choose to wait. A subscription may remain the best deal for the way we work.

But we should be able to explain what happened before the interruption: which task consumed the allowance, what it accomplished, and what comparable metered execution would cost.

The subscription’s limits, eligibility, and future terms are determined by the provider.

Our record of the work should be ours.

Nasiko is now available on the DigitalOcean Marketplace

Shrawan Saproo — Sun, 11 Oct 2026 15:49:42 +0000

Getting an AI agent to production is one thing. Knowing what it costs, what it can reach, and what it is doing once it is running is another, and that is where most teams lose visibility. Nasiko is an open runtime for your agents: one place to run every agent you deploy and know what is running, what it can reach, and what it costs. Because we run the agents, we know the work. Today we are making that easier than ever to adopt, with Nasiko now available as a one-click offering on the DigitalOcean Marketplace.

Fully managed, from the registry up

The DigitalOcean offering runs the fully managed Nasiko runtime, so there is nothing to install or operate. Add it from the Marketplace, click through to open Nasiko, and you'll be signed in automatically via DigitalOcean. From there, you upload any working agent, whether it is a containerized service, a LangChain or CrewAI application, or anything that speaks the A2A protocol. Nasiko validates the package, generates its registry metadata and capabilities on upload, and deploys it. You can also compose multi-step workflows for your registered agents directly on the platform. The registry is your intake, and everything past it runs on the open runtime, which we organize around three questions: what the work costs, what it may do, and what it is.

TokenOps: what the work costs

Because Nasiko runs your agents, it sees every model call and the cost of each one. TokenOps gives you visibility into and control over spend across providers, with an LLM router that routes each request to the right model for the job rather than defaulting to the most expensive option. Our own view, and one we have argued at length, is that budget controls should degrade rather than deny: an agent that stays useful within its limits is one teams leave switched on, rather than hard cutoffs that get disabled the first time they break a workflow.

Policy, Security and Governance: what the work may do

This is where Nasiko governs what your agents are allowed to reach and do. Requests arrive through a single point of ingress with access control in front of them. Secrets are encrypted at rest and injected only at request time, so the agent container never holds a key. And a permission-filtered gateway means an agent sees only the tools and MCP servers you have granted it access to, not everything on the network. Governing behavior is only possible because the work runs where we can see it.

Meta-Harness: what the work is

Some of the most capable agents your team already runs are the coding harnesses developers live with day-to-day, such as Claude Code. They are powerful and largely autonomous, but they usually operate with little visibility into their costs, reach, or behavior. Nasiko gives you that visibility without asking anyone to change their environment or the way they work. Developers keep using the same tools exactly as they do now, and you get insight into agents and harnesses you did not build. This is what open runtime means in practice: it works with the agents your team already uses, not only the ones made for it.

Scaling you do not have to plan for

Nasiko runs whatever you deploy, from long-running agents that stay online around the clock to short-lived agents that burst for an hour and disappear. Scaling is automatic and elastic, adding capacity as your traffic grows and releasing it when load drops. Pricing follows the same shape: a flat monthly subscription with a generous pool of included agent compute, and pay-as-you-go only when you scale beyond it, so your bill tracks what you actually run.

Get started today

Nasiko began as an open-source project and now has a community of more than 2,000 developers on GitHub building agent infrastructure in the open. That same openness runs through the product: an open runtime that meets your agents where they already are and brings them into one managed home. Add Nasiko from the DigitalOcean Marketplace to deploy your first agent, and see the docs at docs.nasiko.com for upload requirements and integration guides.

Nobody Can Prove Who Authorised the Agent. We Checked All Thirteen Protocols.

Shrawan Saproo — Sun, 11 Oct 2026 15:41:21 +0000

We scored thirteen inter-agent protocols on one ten-axis rubric, with a recorded reason for every cell. This is what that found. The full survey is attached.

Every protocol comparison we could find was a narrative. Protocol A emphasises discovery, protocol B has a richer task model, both are promising, more work is needed. Four broad surveys exist and they are all useful. None of them lets you check the comparison.

So we built a rubric instead. Ten axes, ordinal levels, and each level anchored to a property you can find in a specification rather than to a judgement about quality. Then we read thirteen specifications and scored eight of them against all ten axes. For each of those eighty cells we recorded the sentence in the spec that put it at that level.

The point of anchoring the levels is that the scores stop being opinions. If you think A2A deserves better than level 1 on authorisation, you are not disagreeing with our taste. You are claiming a specific clause exists, and we can both go look.

What the rubric found on its third axis

Axis 3 asks how authorisation propagates. Agent A asks agent B to do something on behalf of principal P. Can B prove that P authorised this?

The levels run 0 to 3. Level 1 is OAuth scopes or token forwarding: A hands B its own token. Level 2 is a signed capability with explicit scope, audience, and time bounds, binding two named parties. Level 3 is a chain, where each hop's authority is independently verifiable by an agent that did not witness the grant.

Level 3 is empty. Not sparse. Empty.

Eight protocols scored. The top level of the authorisation axis has no occupants.

Four of the eight sit at level 1 and four at level 2. Not one specifies a delegation chain a third party can check. Every one of them leaves the mechanism to "the surrounding identity architecture," which is a specification-layer way of saying somebody else's problem.

The commerce protocols do reach level 3, which is the detail that makes this worth stating carefully. Their intent, mandate, and receipt envelope gets there by construction, because payment authorisation was never going to work any other way. So the field has a working example of the thing the peer-messaging layer lacks. It just sits in a layer that only moves money.

We went looking for the counterexample, because a universal claim deserves an honest attempt to break it. The best candidate is ACNBP. It has the widest threat coverage in the set, ten of twelve classes addressed, against one of twelve for A2A and MCP. It has a Capability Binding ceremony, which is the most rigorous single-hop primitive we read anywhere. It still binds exactly two parties at a time. A lead author confirmed that this is the intended scope, which is the kind of answer that makes a finding stronger rather than weaker.

Rigour on one hop is not authority that travels. Those are different properties, and the rubric had to separate them before we could see that no protocol has the second one.

Why an empty cell is worth a paper

Because deployments do not wait for specifications. They need delegation to work today, so they forward tokens, and the security literature has already measured what that costs.

The AgentLeak benchmark is the number that reframed this for us. Inter-agent messages leak personally identifiable content at 68.8%. The output channel, the one everybody audits, leaks at 27.2%. Output-only auditing misses roughly 41.7% of violations.

So the gap is an omission at the specification layer with a measured cost at the deployment layer. That is more actionable than "authorisation needs more work." It is the one item we would put at the top of the next standardisation cycle's agenda.

The result we did not expect

We assumed rubric strength would track adoption, at least loosely. It does not. It runs the other way.

The two highest-scoring protocols, ACNBP at 24 points and LOKA at 23, have the smallest deployment footprints we could document. The two with the largest footprints, A2A at 14 and MCP at 10, have modest profiles. A2A and MCP each address exactly one of twelve threat classes normatively.

What predicts adoption is institutional position. Foundation stewardship, vendor backing, ecosystem support. Technical rigour at the specification level predicts very little.

We report this as a finding rather than a complaint, because it has a consequence for anyone doing this work. The highest-impact technical contribution is the one an institution is positioned to adopt. That is an argument for working inside the AAIF and W3C tracks rather than alongside them. We took our own advice.

MCP versus A2A is a category error

The most-debated rivalry in the field is not a rivalry. MCP is a tool-binding protocol, A2A is a peer-messaging protocol, and they occupy different layers of the taxonomy. In production they compose. They do not substitute.

The stack the rubric most clearly recommends is not deployed anywhere: ANP's identity layer underneath A2A's task layer. ANP tops the identity axis on DIDs and verifiable credentials. A2A tops the task axis. No surveyed protocol combines a deployed task model with a decentralised identity model.

The recommendation is specifically the identity layer. ANP's DID mechanism carries no dependency on the rest of its stack. Its description and discovery protocols are a different matter: they overlap the A2A AgentCard and compete with it rather than stacking beneath it.

That distinction only became visible once the axes were scored separately. A single overall verdict per protocol would have hidden it.

What we are not claiming

Every score is one rater's reading. We have no inter-rater agreement statistic, and we say so in the abstract rather than burying it in a limitations paragraph.

What we offer instead is auditability. The scores live in a YAML file, with an evidence string and a citation per cell. Every table and figure is generated from that file, so a table cannot drift from the data behind it. You can disagree with a cell and point at the exact thing you disagree with.

Five of the thirteen protocols are surveyed but not scored. They are the commerce-settlement ones, where six of the ten axes have no referent. A settlement envelope has no task model and no multi-modal content handling. Scoring one of them while the others stayed unscored would move the averages in our own figures for reasons of scope rather than substance. UCP is the interesting case: it would return a defensible score, and we still left it out.

The specifications also move faster than a review cycle. So the survey declares a 2026-Q1 cutoff on page 1, and pins the exact version and commit behind every claim. That precision is not pedantry. One protocol we read ships two release tags that declare the same version string and differ by thousands of lines.

The loop we did not expect to find

We proposed three extensions against the gaps. A workspace naming scheme, a context-selection envelope, and an egress-attestation envelope. We expected three independent proposals.

They turned out to be three legs of one loop. A guardrails envelope with no normative workspace name has to invent a duplicate naming standard. A selection envelope with no boundary notion has nothing to key its policy on. A naming scheme with neither has scope but no enforcement.

Which is the survey's clearest argument for why the rubric axes cannot be worked on independently. Identity, authorisation, and security are one problem wearing three hats, in any deployment that crosses an organisational boundary.

All three are specification sketches for the next revision cycle, not validated standards, and we would rather label them that way than oversell them.

Read The Full Paper Here: https://hal.science/hal-05751265

If a cell is wrong, we would rather hear it than publish it. Several have already changed that way, including one that dropped a score after a lead author told us we had been too generous.

We Scoped Down Our Agent Skill Library. You Might Not Need One at All.

Shrawan Saproo — Tue, 22 Sep 2026 09:47:15 +0000

Part 3 of a three-part series on the memory architecture behind our multi-agent harness. Part 1 covered why agents should share memory instead of passing context. Part 2 covered how the semantic tier handles users who change their minds.

"A library of skills the agents learn." It is a seductive phrase, and it was our original plan for the third tier of our memory architecture: an agent solves something, the system captures the skill it used, and the skill is stored for every agent to reuse. The library fills itself by watching agents work.

That plan does not survive contact with how agents are actually deployed. This post is the honest version of what the procedural tier (L3 in our shorthand) can and cannot do, why we deliberately dropped skill-learning-by-observation as a design goal rather than deferring it, and the one question that decides whether an organization should build this tier at all. By the end, the entire decision compresses into a single yes-or-no question. Spoiler on the answer: sometimes it is no, and we think saying so is a feature of the architecture rather than a gap in it.

First, what a skill actually is

Most of the confusion around skill libraries traces back to definitions, so here is the line we hold.

A tool is a raw capability: calling a PDF library, hitting an API. Tools are wired into the agent. They do not live in memory.

A fact is about a user or the world: "this client wants a house in five years." Facts belong in the semantic tier.

A skill is a procedure: "to extract totals from our vendor's invoices, the total is in the footer, dates are DD-MM-YY, validate the sum against the line items." Learned, reusable, and specific to how one organization operates.

The test for whether something belongs in the procedural tier is that it is procedural, non-trivial, reused, and specific to how you operate. If it is a raw ability, it is a tool. If it is about someone, it is a fact. And if the base model already knows it, it is noise. Keeping that line sharp is what stops the tier from becoming a dumping ground.

Where a skill library genuinely pays off

Four situations, and it is worth noticing they are not four kinds of content. They are four situations in which the same stored artifact gets used, differing only in who benefits.

Avoiding re-derivation. An agent that re-reasons the same procedure on every run can retrieve the proven version and follow it instead. Cheaper, and it cannot get the logic wrong this time, because it is not reinventing it.

Cross-agent transfer. A procedure worked out by one team's agent becomes available to a different agent that never solved it. This is the only case that truly needs organization-level scope; within one agent, it is just memory.

Consistency. Shared conventions, output formats, phrasing contracts, live in one place, so every agent behaves the same way instead of each improvising and breaking whatever consumes its output.

Onboarding. A newly deployed agent inherits the accumulated procedures immediately and starts competent rather than naive.

All four share one mechanic: an agent describes a need, and the library returns a procedure that was authored once and reused. Hold onto the word "authored." It is about to matter.

The wall: you cannot capture skills from a hosted API call

Here is where deployment reality bites. Most production agents today are calls to hosted models. The call returns output, and nothing else. There is no reasoning trace, and there is not even a discrete "skill" inside a completion to capture. The model produced tokens.

You cannot store a skill you never observed.

So any attempt to extract "the skill the agent used" from a response is reverse-engineering a plausible-looking procedure from the answer alone, with no way to tell whether it reflects what actually produced the result. Our own episodic log does not rescue this either: it records agent outputs, not reasoning traces, so mining it for procedures hits exactly the same wall.

In our assessment, this failure mode is worse than storing nothing. A confident, clean-looking skill that does not reflect reality will get retrieved, trusted, and reused, and then it will fail somewhere downstream where nobody is looking for it. An empty library is honest. A library of plausible guesses is a liability.

The conclusion we reached is worth stating as bluntly internally as we did: populating a skill library by observing running agents is a dead end for hosted models, and we dropped it as a design goal rather than deferring it. It becomes worth revisiting only if two things become true at once: faithful action traces are captured, and we own prompt construction for that agent. Neither is on the horizon for the deployments we see.

The reframe that keeps the tier usable

The black-box call only kills the tier if you think the tier's job is to observe skills from runs. It is not. There are two directions of traffic, and only one of them is affected.

Writing to the library happens by authoring. A person writes a skill file. A vetted skill is imported from a public library. An agent is explicitly asked to write one up after a success, as a deliberate act with review. In every case the skill is created on purpose as an artifact, never harvested passively from a run. Authored, not observed.

Reading from the library works fine for a black-box agent. The orchestration layer retrieves the relevant skill and injects it into the prompt before the API call. You do not need to see inside the model. You control the input to it.

That last clause is the real precondition, and it is the question we now ask before anything else in an integration. Not "can we see inside the model," because nobody can. The question is: **do you control the prompt that goes into it? **If the agent is custom and your platform assembles its prompt, the skill tier works. If it is a sealed third-party agent product where you only hit an endpoint, the tier has nothing to attach to for that agent, and no amount of library curation changes that.

The harder question: store skills, or just download them?

Even granting all of the above, there is a fair challenge that deserves a straight answer: why curate a library speculatively when an agent could fetch a skill from the public ecosystem at the moment it needs one?

One distraction to clear first: storage cost is a red herring. Skills are small text files; a few hundred of them amount to megabytes. The real cost of pre-storing is human effort, the selecting, reviewing, security-scanning, and maintaining of the library. So the honest comparison is curation effort versus fetching on demand.

Download on demand wins when skill needs are unpredictable and long-tailed (you would curate five hundred and use twelve), when the skills are generic (read a PDF, scrape a page, parse a CSV) and the public ecosystem already maintains them better than you will, and when nothing the agent does is specific to your organization. For a team running hosted-model agents on generic tasks, that is usually the whole picture, and the right recommendation is to skip the library and fetch.

The one question that decides it

Per deployment, everything above compresses into a single question: does this agent rely on procedures that are either unique to the organization or too sensitive to run unreviewed?

If yes, that slice justifies a small, curated procedural tier, populated by authoring and read by prompt injection.

If no, download on demand and do not build the tier. And if that answer holds for a given deployment, we would rather say so than sell a tier that sits half-empty. An architecture that tells you when one of its own components is unnecessary is, we would argue, more trustworthy for it.

That closes the series. The episodic tier is the append-only truth. The semantic tier is one belief per fact, with the history to prove it. And the procedural tier is smaller than the hype suggested, on purpose, and everything in it is authored, not observed.

Memory Architecture Series Part 1: Agents Shouldn't Pass Context. They Should Share Memory. Part 2: One Belief Per Fact: Building Agent Memory for Users Who Change Their Minds Part 3: We Scoped Down Our Agent Skill Library. You Might Not Need One at All. (this post)

One Belief Per Fact: Building Agent Memory for Users Who Change Their Minds

Shrawan Saproo — Tue, 22 Sep 2026 09:37:59 +0000

Here is a scenario that breaks most agent memory systems.

In session one, a user tells your financial advisory agents she is cautious with money and dislikes individual stocks. The system remembers it. In session two, she has changed her mind: she wants to go aggressive, individual tech stocks. The system remembers that too.

Now session three begins, and an agent asks memory: what is her risk appetite?

If your memory layer stores a row per session, it returns both answers, side by side, with no way to choose. We know because that is exactly what our first version did. This post is about how the semantic tier (L2 in our shorthand) actually works: what gets embedded, how beliefs update, and what happens on a contradiction. We will use one running example throughout, a user named Priya, drawn from the synthetic test scenario we ran the design against.

How we broke it first

The first cut of the semantic tier keyed facts by session. Every session inserted new rows, so after a handful of sessions there were six copies of Priya's risk tolerance, some of them contradicting each other, and no notion of "current." Retrieval surfaced whichever ones ranked highest, which meant a downstream agent could receive "cautious" and "aggressive" in the same context window.

Two other bugs from that first version are worth confessing, because they shaped the fixes. The transaction analysis agent invented income growth it was never told about, which led to a hard grounding rule: only figures explicitly stated in memory, otherwise answer "unknown," never estimate. And our "semantic" search was not semantic at all: the store had been created without an embedding index, so nothing was ever vectorized, and we were doing keyword matching while believing otherwise. The fix included a runtime check that the vector table is populated and that a paraphrased query actually retrieves the right belief.

The structural fix for the main bug is the subject of this post: one belief per fact, current, with the versioned history to prove it. That phrase is the whole design; everything below is what it takes to make it true.

What actually gets embedded

There are two embedding moments, and keeping them separate clears up most confusion about how retrieval works.

The write side. After a session, an asynchronous projector reads the raw episodic log and asks an LLM to break each entry into typed, self-contained fact sentences. From Priya's intake record it extracts something like:

Only one field is embedded: the text sentence. The store is configured to embed that field alone. The sentence goes to an embedding model and the resulting vector is stored in a separate vector table. Everything else, the key, the version, the flags, the provenance, is plain metadata for identity, filtering, and audit. It is never embedded.

The read side. When an agent asks "what is her appetite for investment risk?", the query sentence is embedded with the same model, and the nearest stored vectors win. The query and the stored fact share almost no vocabulary and still match, because both are compared by meaning.

One design point matters more than it first appears: identity never depends on the embedding. Which belief is which is decided by the stable key. The embedding only decides ranking at retrieval time. A weak embedding model can degrade what surfaces first; it can never corrupt the record.

The division of labor compresses to three words each: embeddings retrieve, keys identify, metadata governs. If you take one thing from this section, take that.

One current belief, a version chain behind it

The stable key is the fact type: risk_tolerance, house_goal, city. It is independent of session. That single change inverts the growth behavior of the tier: it grows with the number of distinct facts about the user, not with usage. Ten sessions restating "cautious" still produce one belief.

The update procedure is search-then-decide. When the projector extracts a new fact, it first fetches the existing belief under that key, then an LLM compares old against new and returns exactly one of three verdicts:

SAME: no new information. Append this session to the provenance list. No new version.
UPDATE: a compatible refinement or change. Archive the old version, write the new one.
CONFLICT: a direct contradiction. Archive and supersede, and set the contradiction flag.

Here is Priya's flip, before and after. After session one:

Session 1
risk_tolerance -> {
  text: "cautious, dislikes stocks",
  version: 1,
  current: true,
  flag: false
}

Session 2
risk_tolerance -> {
  text: "aggressive, individual tech stocks",
  version: 2,
  current: true,
  flag: true,
  provenance: [S1, S2]
}

risk_tolerance__v1 -> {
  text: "cautious, dislikes stocks",
  version: 1,
  current: false
}

There is a history, but it is a version chain hung off one stable key, not a pile of equal rows. The current belief is the single row at the bare key. Past versions are archived with current: false and are not read by default.

Retrieval then needs two mechanisms working together: vector search finds the relevant fact by meaning, and a current: true filter picks the live version. The agent sees one clean answer, the newest belief, instead of the version-one situation where both came back with no way to choose.

The contradiction policy: flip, preserve, flag

When a CONFLICT is detected, three things happen at once, and the design is deliberately not "silently overwrite."

First, the current belief flips to the new value. Agents act on the user's most recent intent; the default read is most-recent.

Second, the old belief is preserved as history with full provenance. "What did she used to want, and when did it change?" stays answerable. Nothing is destroyed.

Third, the contradiction flag is set, which tells the system this belief flipped rather than smoothly refined. Downstream agents can key off it. In our chain, the compliance agent does exactly that: "note: your current aggressive strategy conflicts with your earlier caution and your house-fund goal."

Why resolve to most-recent instead of reconciling the two? Because deciding which of two contradictory beliefs is really true requires judgment the memory layer should not be making on its own. It would need a stance classifier and context it does not have at write time. So the layer's job is kept narrow and safe: surface the newest, preserve the old, flag the conflict. The decision about whether to honor the shift is handed to an agent or a human. In our view, a memory layer that quietly adjudicates its user's changes of heart is a memory layer you cannot trust. One belief per fact does not mean one truth per fact; it means one answer per question, with the disagreement on record.

The limitation we have not fixed yet

Honesty requires one more section. The projector treats each fact type as a single evolving slot, and superseding is correct for single-valued facts: risk tolerance, income, city. A new value should replace the old.

It is not automatically correct for multi-valued facts. "Buy a house" and "save for a baby" are both true at once; the second must not supersede the first. The current build handles this by having the extraction step assign distinct fact types (house_goal, baby_goal) so goals coexist, but that relies on the extraction LLM choosing distinct keys, which is a soft guarantee. If two goals collapse onto the same key, one wrongly overwrites the other.

The clean fix, documented but not yet built, is to mark certain fact types as multi-valued so they append as a set while single-valued beliefs keep the supersede behavior. The test is straightforward: add a second goal and assert both survive, while a risk-tolerance flip still supersedes.

Recap

What is embedded: only the distilled fact sentence, never the metadata. What is matched at read time: the embedded query sentence against embedded fact sentences, same model on both sides. How the tier grows: with distinct facts, not with sessions. One belief per fact, a version chain behind it, and a flag when the story changed. Embeddings retrieve, keys identify, metadata governs, and the judgment calls are deferred to something with more context than a database.

Part 3 turns to the tier we have said the least about: the procedural tier, the "library of skills the agents learn." That phrase turned out to promise a great deal more than the tier can deliver, and the reason why changed what we built.

Agents Shouldn't Pass Context. They Should Share Memory.

Shrawan Saproo — Wed, 02 Sep 2026 08:00:41 +0000

Every additional agent in a chain is supposed to make the system smarter. Too often, it just makes the prompt bigger.

This is the failure mode almost every multi-agent system runs into, and it has nothing to do with model quality. It is token accumulation. Agent A finishes its work and hands everything to Agent B. Agent B adds its own output and hands all of it to Agent C. By the sixth agent in the chain, the prompt is carrying five predecessors' worth of context, needed or not. Then the same user comes back tomorrow, and the whole pile becomes the starting point for session two.

Costs climb. Latency climbs. And attention dilutes: the model is asked to find the three relevant facts inside forty thousand tokens of transcript.

We hit this building a proof of concept for a six-agent financial advisory chain: intake, transaction analysis, goal planning, market context, recommendation, and compliance, running in sequence, with the same user returning across many sessions and expecting continuity. This post describes the memory architecture we built to solve it, and the design decision everything else rests on.

The core idea: pass by reference, not by value

The instinctive way to connect agents is to pass context by value: each agent sends the next one a full copy of everything it knows. That is what makes tokens accumulate at every handoff.

Our design passes by reference. Agents do not hand anything to each other directly. Each agent writes its output to a shared memory layer, and the next agent retrieves only the slice it needs, capped to a token budget. If Agent A produced forty thousand tokens of investigation and Agent B needs the three thousand tokens of conclusion, B receives three thousand.

The consequence is worth stating plainly: token reduction becomes a property of how communication happens, not a feature bolted on afterwards and demonstrated with a benchmark. The budget bounds every prompt no matter how long the chain runs or how many sessions accumulate. In our team's experience, this reframing, from "how do we compress context" to "why are we copying context at all," was the single most consequential decision in the design.

In operational terms, passing by reference is the difference between a system whose cost grows with every conversation and one whose cost stays predictable months into a deployment. We think this belongs to a broader engineering discipline: TokenOps. Not prompt engineering, not model optimization, but designing systems whose token consumption is structurally bounded. The rest of this post is what that looks like in practice.

Three tiers, three jobs

Once we stopped copying context, the next question became obvious: where does the context live instead?

The memory layer has three persistent tiers. We refer to them as L1, L2, and L3 internally, but their real names describe what they hold.

The episodic tier (L1) is an append-only log of everything that happens in a session: every agent output, tagged with an identity tuple that records which tenant, which session, which step in the chain, which agent, and the sequence of the write. Nothing here is distilled, deduplicated, or embedded. It is the raw record and the source of truth. Writes are synchronous: an agent's turn is not done until its row is in the log.

The semantic tier (L2) holds distilled facts that persist across sessions: "this user is cautious with money," "this user wants a house in five years." Where the episodic log is keyed by when something was said, the semantic tier is keyed by what the fact is about. It holds one current belief per fact, with versioned history, and it is vector indexed so agents can retrieve facts by meaning rather than by keyword. Part 2 of this series is entirely about how this tier behaves.

The procedural tier (L3) holds reusable skills: organization-specific procedures for how to do something well, authored deliberately rather than learned by observation. It is the tier we scoped down the most, for reasons that deserve their own post. That is Part 3.

One rule ties the tiers together: facts flow upward, never back down. The episodic log is raw truth. The semantic tier is a projection distilled from it. The procedural tier is a library read alongside them. Because L2 and L3 are projections, they can always be rebuilt from L1. If an extraction bug corrupts your beliefs, you replay the log. Nothing downstream is ever the only copy of anything.

The write path: fast now, thorough later

Distilling raw output into clean facts requires an LLM call, and putting an LLM call on the hot path of every agent turn is exactly the latency this design exists to avoid. So the write path is split in two.

During the session, agents append to the episodic log synchronously. The write acknowledges as soon as the row lands. That is the whole cost an agent ever pays to write.

After the session, an asynchronous projector reads the new log entries, extracts typed fact sentences with an LLM, and merges them into the semantic tier using a search-then-decide procedure (Part 2 covers this in detail). Because this runs off the hot path, it can be slow, retried, or re-run entirely without touching agent latency. The semantic tier is a projection that is allowed to lag.

The read path: hybrid retrieval closes the gap

If the semantic tier is allowed to lag, a reader could see stale data. The fix is that no agent ever reads only one tier. Every retrieval queries the episodic log (fresh, raw, this session) and the semantic tier (distilled, cross-session) together, merges and deduplicates the results, and packs them into a fixed token budget before anything enters the prompt.

This has a property that took us a while to appreciate: the projector's lag is invisible. Anything too fresh to have been distilled into the semantic tier is, by definition, still in this session's episodic log, so the reader sees it from there. The agent is never blind, and the distillation never blocks anyone.

The budget allocator defaults to an even split between the two sources, on the logic that a typical turn needs both "what just happened" and "what do we know about this person."

Reads stay real-time throughout: log lookups are indexed table reads, and vector search over distilled beliefs is fast because the tier is small by construction.

Why the reduction is structural

Four mechanisms, all architectural rather than tuned:

Communication is by reference. No agent's prompt ever contains another agent's full output, only the retrieved slice.
History is queried, not accumulated. The agent at turn ten does not carry turns one through nine verbatim. It queries recent raw events and older distilled facts and receives a budget-capped slice.
Distillation happens once, at write time. Turning a thousand-token observation into a fifty-token fact costs one asynchronous LLM call. Every later read pays only the small cost. Naive context passing pays the large cost on every turn.
Large blobs are stored by reference too. Tool outputs and files live in object storage; the log keeps a pointer, and the allocator inlines a blob only when it is relevant.

Informally: the naive cost per round is the sum of every agent's full history, and it grows without bound. This architecture's cost per round is the sum of each agent's budget-capped slice, and the budget is fixed. The gap between the two is the reduction, and it widens as sessions and agent counts grow.

What this looks like in a chain

In the six-agent chain, the "turn" is an agent. Each agent reads a capped slice of memory that already contains everything agents before it wrote, does its work, and appends its own output back to the log. The shared context of the chain is the log itself, not a payload passed hand to hand. When the user returns for session two, the semantic tier's cross-session beliefs feed the reads from the first turn, so the chain starts already knowing the user without replaying session one.

The same primitive covers single-agent multi-turn work, sequential chains, and parallel multi-agent rounds. That universality was a design goal: one session model, with a round counter and an agent identifier, rather than a special case per workload.

What's next

Replacing context passing with shared memory solved the scaling problem. It immediately exposed a harder one: what happens when memory itself changes? What exactly gets embedded, what happens when a user contradicts something they said last month, and how does the system avoid returning two conflicting beliefs with no way to choose? That is Part 2.

And then there is the tier we have not really discussed. The procedural tier sounds, on first hearing, like "a library of skills the agents learn." We started there too. Part 3 is about why that phrase promises more than the tier can deliver, and what we built instead.