fast-agent

You will know within ten minutes whether this is for you. Attaching a new tool server is a command typed mid-session rather than a configuration file and a restart, and that immediacy is the deciding daily trait, because the reason people stop extending their agent is the twenty-second gap between wanting a capability and having it.

Pick it if your work is built around external tool servers and you want the agent that treats them as the point. Pick Goose when you want the same orientation with more polish and fewer specification details in your face.

A completeness claim is only as good as the evidence behind it, and the evidence here is a sentence. Nothing links to the coverage that would show which features were tested, against which servers, at which protocol version, which matters because the harder corners of this specification are exactly where implementations diverge. Authentication in particular fails by returning something plausible rather than by erroring.

What it does right: shelling out is an explicit character you type, not a decision the agent makes, so command execution stays a human act.

1. Pulling capabilities from a registry, including language-server integration, hooks, compaction and automation, turns the agent into a small core with replaceable parts, which is a defensible architecture and unusual in a terminal tool. 2. Compaction being a skill rather than a built-in means the strategy is visible and substitutable, at the cost of nobody owning whether it works. 3. Subagents split work into separate contexts.

No evaluation of any skill is published. The observation: making the context strategy pluggable is the right call and it moves the burden of proof to the user.

Being first and most thorough on a specification is a reputation, and reputations do not compound the way products do. There is no entity, no pricing and no hosted component, so the value accrues to the maintainer's standing rather than to anything a buyer could acquire, and the position itself erodes as other implementations catch up on a spec that is public.

Likely path: the maintainer is hired by a company that wants that expertise, which is the usual and honourable outcome. Position: excellent tool, no company, and plan for the day the commits slow.

One sentence on the demo: it connected to three of our internal servers in under a minute, which was genuinely impressive. Commercially it is free and installs per developer, and the packs that configure it against an existing consumer subscription mean part of the team incurs no new spend at all. Against that, there is no console, no identity integration, no telemetry we control and nothing that runs on its own, so this is personal tooling and cannot be anything else.

Onboarding is half a day. Approved with conditions: personal use, no production dependency.

This is the one that assumes I run my own models rather than tolerating it. There is a generic provider for any endpoint I point at, and the command line will write the configuration for a local inference runtime without me reverse-engineering a schema, which is the difference between supported and technically possible.

It is a protocol client and a protocol server, so my existing servers attach and this agent becomes callable from everything else I run. Permissive licence, readable Python, one install command, no account. If the maintainer stops, I keep all of it.