agent

The convenience of MCP comes with a price, stemming from two architectural attributes of an MCP-driven application. MCP creates incoherent toolsets and separate runtimes.
Since tools are drawn from arbitrary sources, they are not aware of what other tools are available to the agent. Their instructions can't account for the rest of the toolbox.
The second issue stems from different toolsets having their own runtimes.

Every Ditto user already has a knowledge graph. As you talk, Ditto extracts subjects (typed topics, people, projects, preferences) and links each one to the memories it touches. (That’s the dreaming pipeline at work.) We’d already seen that matching a query to subjects, rather than only to raw memories, was a powerful signal. v4 leans on it directly.

Storing memories is easy. Finding the right one from a vague question is the hard research problem. When you ask Ditto something indirect, like “what did I decide about that thing a while back?”, there’s no keyword to match on, just a fuzzy query against a haystack of everything you’ve ever told it.

These results show that a model’s capabilities are compatible, generalizable and can carry over to other harnesses. Providers do report to optimize some models for their own coding environments: OpenAI, for example, describes GPT-5-Codex as optimized for agentic software engineering in Codex.12 Yet we observe that a shared provider does not guarantee the best pairing. The practical question remains which harness delivers the best balance of cost and task success for a given model and workload.

A graph in the context of AI work is simpler than it sounds: it's a map of which jobs need to happen and what each one depends on.

We leverage probabilistic programming principles to tackle complex tasks, and utilize differentiable and classical programming paradigms with their respective strengths. The framework introduces a set of polymorphic,
compositional, and self-referential operations for multi-modal data that connects multi-step generative processes and aligns their outputs with user objectives in complex workflows. As a result, we can
transition between the capabilities of various foundation models with in-context learning capabilities
and specialized, fine-tuned models or solvers proficient in addressing specific problems. Through
these operations based on in-context learning our framework enables the creation and evaluation of
explainable computational graphs. Finally, we introduce a quality measure and its empirical score
for evaluating these computational graphs, and propose a benchmark that compares various stateof-the-art LLMs across a set of complex workflows.

One threat we’re particularly focused on is prompt injection, and we handle it in layers. The model is trained to recognize and resist it. The harness marks anything coming from an untrusted source. Deterministic code checks the result. And an ensemble of classifiers runs where the agent can't reach them.

Both interruptions and auto-approvals increase with experience. This apparent contradiction reflects a shift in users’ oversight strategy. New users are more likely to approve each action before it’s taken, and therefore rarely need to interrupt Claude mid-execution. Experienced users are more likely to let Claude work autonomously, stepping in when something goes wrong or needs redirection. The higher interrupt rate may also reflect active monitoring by users who have more honed instincts for when their intervention is needed. We expect the per-turn interrupt rate to eventually plateau as users settle into a stable oversight style, and indeed the curve may already be flattening among the most experienced users (though widening confidence intervals at higher session counts make this difficult to confirm).

We have been exploring how agents can build on that coordinate system. The files and symbols earlier agents repeatedly read, edited, cited, or returned to can become landmarks for the next agent, resolved against the code as it exists now and linked back to the conversations where that understanding was formed. By preserving the causal metadata beneath that surface representation, like which operation produced each fragment and what prior state it built on, DeltaDB gives the model a way to traverse not just the current code, but its provenance, accumulated attention, and prior reasoning.

By enforcing capability-based security policies,
CaMeL effectively prevents unintended data
flows and actions. Even with a compromised
cloud storage file containing prompt injections
targeting the Quarantined LLM, the capabilities system acts as a robust and granular control mechanism, preventing data exfiltration, as
well as other prohibited actions. This approach
provides a secure environment for LLM agents,
preventing harm by design, without requiring
modifications to the underlying LLM itself, and
offering a significantly more fine-grained and
robust defense compared to isolation and/or
adversarial training strategies alone.

That’s why we’ve decided to approach the software factory category as infrastructure rather than as a factory product or AI teammate.

LLMs are not great at following commands. They deviate. Frequently. And they’re unreliable at self-verification—they’ll confidently tell you the code works while it’s on fire. The fix isn’t to ask the LLM to verify. It’s to ask it to write a script that verifies. Shift from judgment to artifact.

And so generating code is not necessarily the part that you need to worry about the most. Given enough context, agents can write the implementation and run the tests and inspect failure and revise code for us. We need to get to a place where we feel like there is enough of human taste encoded in the environment that we can trust what is being built, so that our human attention can be focused on the places where it’s needed most.

Instead of asking an LLM “Did this work?” you define verification steps that produce a series of pass/fail artifacts. The agent can’t negotiate with a failing test. It either meets the specification or it doesn’t.

give Sol a grid with a "randomized" obstacle to navigate.
Tell it to use a hashmap solution for formulating pathing.
As soon as it runs into its first pathfinding problem (It will) it will start writing edge-case solutions, rather than fixing the core hashmap.

We argue that coding agents have crossed a threshold of capability at which traditional human code review is no longer a necessary component of a software quality pipeline. Our argument rests on two claims: every stated goal of code review can be served by agents at lower cost and higher throughput; the naive integration in which agents write code and humans remain the mandatory reviewers is a dead end because it neither provides meaningful assurance nor scales with AI-assisted throughput.

a cloud software factory is just an automation around the core loop of development, from triage → spec → implement → review → verify → ship → monitor, where at every step a mix of agents and humans moves the process forward.

The 2026 GenAI Code Security Report found that roughly 44% of AI code generation tasks introduced a risky security vulnerability in tests. The average security pass rate across models is 56% – barely changed from 55% in the first report. In other words, security performance has stayed flat while the amount of AI-generated code entering pipelines has surged.
That is why GenAI code security is now a scale problem, not a theoretical risk discussion. If AI is responsible for half the codebase and vulnerable output remains this common, every organization needs a sharper strategy for model selection, verification, remediation, and governance.

The core insight is this: AI agents don’t save you time by finishing your work. They expose how much work was always possible but never attempted. Five constraints now govern how much of that backlog any organization can actually capture: judgment, planning, coordination, evaluation, and absorption. Understanding those five constraints tells you exactly which new roles are being created and why.

the Unix / Linux Environment is a natural candidate, and could be turned into an Agentic harness with a few modifications.

An agent optimizing for passing tests will find ways to pass them. If the tests were written after the implementation, they are likely testing what the implementation happens to do rather than what it should do.

You cannot write a spec that survives that environment unless you deeply understand the architecture, the integration boundaries, the edge cases, the failure modes, and the invariants that must never break. The spec is not a prompt anymore. The spec is the product thinking made explicit.

Agents doing judgement-heavy work need a way to learn from the people whose judgement they are trying to approximate. 1. Principles beat rules, because rules overfit and principles transfer. 2. Agents need to learn how to learn, or feedback turns into brittle exceptions. 3. The feedback loop has to live where the team already works, or people stop participating.

The infrastructure that needs to exist to support this model at scale includes better automated regression detection, artifact-level validation that goes beyond diffing changed lines, reliable and fast environment provisioning, and guardrails that hold up under parallel workloads.

Feedback is not learning unless the agent can generalize

Agents run tools in a loop to achieve a goal

If you cannot articulate what success looks like in a way that can be evaluated, no amount of autonomous execution will produce it. Agents cannot clarify requirements they are never given. They will fill the gaps with assumptions, and those assumptions compound.

It's less about crafting individual assets and more about building systems with enough flexibility to serve a range of needs and enough structure to stay coherent at scale. Brand guidelines become agent-legible rules. A component library becomes the guardrails within which agents make decisions. An internal asset system that automatically tags images for color, text, and usage context means an agent can query for the right image rather than grabbing whatever's most recent.

When an agent does work repeatedly, the prompt starts to become the thing you review. If those instructions determine production behaviour, they should live in a repo, with version history, review, and rollbacks. The daily learning agent does not directly change production behaviour. It opens a PR showing what feedback it reviewed, what principle it thinks should change, and the exact diff to the skill file. A human reviews it like any other change.

handwrite your user level AGENTS.md that holds your preferences, and treat your project level ones like a neural net. Give it a size budget and train it on the sessions that actually ran.

Every SaaS business will become a harness around a model, whether or not they’ve realized it yet.

long-horizon agents assume requirements all exist upfront. They are fundamentally against human in the loop. And they don't have true judgment for what humans like. That—is why I don't like them.

Harrison’s 4 elements of an agent remain – the system prompt, planning tool, file system, and subgents – describing the core loop. This is the core loop the developer controls with the keyboard. The harness manages everything beyond this, the world the developer sits within.

Reacting to an event, running a sequence of isolated subagents, and separating their reasoning from the actions they’re allowed to take — it’s all just a workflow. One that could run just as well from a Slack message, a cron job, or a webhook as from a GitHub issue. Generalizing that realization into a runtime that works the same way regardless of where it’s deployed, or which model it’s driving, is what became Flue: an open, platform-agnostic framework for building durable agents and workflows.

If this continues, there’s a world where 3rd party harnesses become less valuable when used with frontier lab models because the 1st party harness behavior is already baked in. And there’s no longer a fine tuning escape hatch to generalize this behavior away.

I get pushback that falling inference prices will eventually bring us back to sending everything through the largest models. But I’m not so sure: those same gains will benefit the K3s and Qwens, and as we continue to develop better harnesses it will be easier to provide weaker (but still great) models with sufficient context to perform well.

It’s going to be funny if the network effects the AI labs have been searching for end up looking just like the network effects of the SaaS era. Coding harnesses, managing the environments around the agent, look a whole lot like the SaaS platforms of old.