Agents and APIs Boston: Inference Designed for Long Agent Workflows
Table of Contents
1. Event
| Field | Value |
|---|---|
| Event | Agents and APIs Boston Developer Meetup |
| Host | Postman; hosted by Pooja Mistry |
| Date | Thursday, 27 August 2026, 17:30–20:00 |
| Venue | Two International Place, Boston MA 02110 |
| Listing | luma.com/boston-august |
| Format | Talks, live demos, food; Discord for speaker resources |
2. Subconscious: the problem, as they frame it
Figure 1: Slide: a coding agent's context over a run, against the same run under compression
The setup names Claude Code by name: "let's look at a standard coding agent reasoning trace like Claude Code. Over the course of the run the agent accumulates context. A large amount of that information becomes garbage." The left chart plots agent context window against total tokens encountered as a sawtooth climbing to the ceiling, each tooth a compaction, with a photograph of literal refuse pinned to the peak.
The right chart is the same axes under their system: many small teeth, never approaching the ceiling. The claim is that context compression plus caching "massively increase efficiency and accuracy of running agents."
Two things are worth separating here. The observation is sound and familiar to anyone who has watched a long agent run: context fills, gets compacted in a lump, and refills. The claim is that smoothing that sawtooth improves accuracy as well as cost, and that is asserted rather than evidenced. No figures appeared on either slide.
The accuracy half is the one to press on. Cheaper is easy to demonstrate; better is not, and a compression scheme that improves the average case can still lose the one message that mattered. Which is the attribution problem again, and this deck does not mention it.
3. Subconscious: an inference system designed for agents
Figure 2: Slide: Subconscious, "An inference system designed for agents"
The pitch is a segmentation. Workloads are placed on two axes, step count against tokens per step, giving four quadrants: short chats, long single prompts, many steps with few tokens, and long agent workflows. Only the last is claimed, with the line "the best infrastructure available." The argument is that agent traffic is a different shape from chat traffic, and that serving it well is its own problem.
Two mechanisms, as stated on the slide:
- Auto-compression: "messages that stop mattering are scored, marked, and compressed in place. The context goes back to the agent."
- Highly efficient caching: "we match cached tokens on both sides of a compressed span, prefix and suffix, so a pruned thread still hits the cache."
3.1. Why this is worth recording
The compression claim is a forgetting policy sold as an inference feature. "Messages that stop mattering are scored" is exactly the decay question in forgetting and attribution, relocated from the agent's memory layer down into the serving layer, where the agent does not participate in the decision. That is a real architectural position and it has a testable consequence: if the scorer is wrong, the agent cannot know what it lost, because the context it gets back looks complete.
The caching claim is the more interesting engineering. Prefix caching is standard; the difficulty with any compression scheme is that editing the middle of a thread invalidates every cached token after it. Matching on both sides of a compressed span is the move that keeps compression from destroying the economics that motivated it.
Against the same day's other event: the Neo4j workshop put memory above the model as a graph the agent reads and writes, with reasoning traces as their own layer. Subconscious puts it below, as a serving-time transform the agent does not see. Both were pitched on 2026-08-27 in Boston, four hours apart, as the way to handle long-horizon agents. They are not compatible framings, and neither was presented as a choice.
3.2. Not verified
- Nothing here is measured. The slides' claims are the vendor's.
- No numbers appeared on either slide: no compression ratio, no cache hit rate, no latency figures, and nothing at all behind "accuracy".
- The charts are illustrative. Neither carries units on the y-axis.
- Whether "scored" means a learned model or a heuristic, and whether the agent can inspect or veto what was compressed.
- The other talks on the programme.
4. Follow-up
- Ask whether the compression decision is legible to the agent after the fact. An agent that cannot enumerate what was dropped cannot attribute a wrong answer to a missing message, which is the failure the attribution work is about.
- Compare against the same question in the harness: a context-management layer inside the harness is auditable; one inside the inference provider is not.