Seven positions on running AI agents at work

The future is multi-model and multi-harness

Teams are standardising on one coding agent from one vendor. It is the reasonable thing to do, and we think it is a mistake, because the thing being standardised on turns over faster than the decision to standardise does. Frontier leaderboards reorder in months. Contracts and habits last years.

So we build for the opposite. Streampipe discovers what is installed on your own machine and routes work to it. If you run Claude Code on one box and Codex on another, that is a routing decision, not a migration.

Portability over polish, and polish still matters. A single-harness product is easier to build, easier to demo and easier to support. We gave that up. In exchange we inherit every difference between one customer's machine and the next, and we spend real engineering on it.

Intelligence is becoming a commodity, in one specific way

The careful version of this claim is the only one worth making. The price of a capability you already have falls fast. The price of the newest capability does not, and the gap between open and closed models has not closed on a schedule anyone predicted. Both things are true at once, and a manifesto that flattens them into "AI is getting cheap" is selling something.

What follows from the true version is a pricing decision. We do not mark up your inference. You bring your own subscriptions and keys, they stay yours, and we charge for the command center. That is a worse business than reselling tokens at a margin and we chose it deliberately, because a company that profits from your consumption has a reason to want more of it.

The cost to us is legible: our revenue does not grow when your usage does.

Knowledge management is the new context management

Most agent failures we have watched were not reasoning failures. The model did competent work against a picture of the company that was wrong, missing or a week stale. Prompt engineering became context engineering, and context engineering is turning into something companies have been bad at for thirty years, which is writing down what they know and keeping it current.

There is a measured wrinkle worth knowing before you automate this. Context written by people helps. Context written by models, left uncurated, has been measured doing nothing or slightly hurting. A knowledgebase that agents fill and nobody reviews is not an asset.

So Streampipe keeps your knowledge as markdown in a git repository on your own hardware. That copy is the real one. Our search index is derived from it and can be rebuilt from your machine at any time, which means it is not a moat we own. When you ask us what we would still hold after you left, the honest answer is an index we can throw away.

Human in the loop matters more, not less

The demo where an agent goes away and returns with finished work is the one everybody wants to give. We will not give it. In Streampipe a session that finishes has produced a proposal, and it goes to a review queue. Approving is the thing that merges the branch and pushes it. Nothing reaches your default branch because an agent decided it was done.

This is not caution for its own sake. Developers are the most sceptical audience for this technology, not the least, and the refusal is specific: the survey work shows they will use agents to write code and will not hand them deployment and monitoring. That is a judgement about blast radius, and it is correct.

Review over autonomy, and autonomy still matters. The cost to us is the demo. The cost to you is a queue.

We will keep this behaviour when customers ask us to remove it.

If you cannot see it, version it, or price it, you do not own it

An agent that did something useful and left no record is a story, not an asset. Every run in Streampipe records what model actually ran, tokens in and out, cache reads and writes, turn count, the notional cost, and the git facts: which repository, which branch, which base commit, whether it pushed. Absent usage is stored as absent rather than as zero, because a zero is a claim and a null is the truth.

Versioning is the same argument one layer down. The work lives on a branch in your repository, so the record of what an agent did is the same artifact your engineers already know how to read, revert and blame.

Publishing the numbers has a cost we accept: it makes them arguable. A customer can look at a run and tell us it was not worth what it drew.

Multi-agent needs multi-human

The strongest argument against this position is worth stating properly, because you have probably read it. Cognition published a piece called "Don't Build Multi-Agents", and its core claim is right: parallel agents making decisions in isolation produce work that does not compose, and a single-threaded agent with the full context beats a committee of confused ones.

Where we disagree is about what the second agent is for. Running five agents in parallel on one problem is the failure that argument describes. Running five agents across five problems, each answering to a person who owns that area, is how a company already works. The coordination that makes it work is human coordination, and it is the part being skipped.

Coordination over parallelism, and parallelism still matters. As a fleet grows, the constraint stops being how many agents you can run and becomes how many people can meaningfully review what came back. That is a real ceiling and we would rather name it than sell past it.

Defaults are a starting point, not a policy

Every agent product ships defaults. Ours too. The question is whether you can change them and then find out whether the change helped, and the second half is the part that usually does not exist.

Being able to swap the model, the harness or the effort level is table stakes and by itself proves nothing. What makes it worth doing is a record complete enough that a change of routing can be measured against outcomes rather than argued about in a meeting. That is why position five comes first: the measurement has to exist before the experiment means anything.

We are saying this before we have finished building it. Task-level routing across model and effort is not in the product today. Repository routing is. We would rather write down the order we are building in than imply it is done.