Clay Studio

The deciding trait is that other people can be in the session with you. Live activity is visible, a teammate joins the run you started, and work hands off mid-task instead of being described in a message afterwards. Anyone who has narrated an agent's progress to a colleague over a call will feel the difference.

If you work alone, all of that is machinery you are paying for in setup and getting nothing back from. Pick it when two or more people share the same repository and the same agents. Pick a single-user harness when the only person who needs to see the session is you.

The hazard is ambient approval. A prompt asking whether the agent may proceed is answerable by any teammate in the workspace, so the person who understands the change and the person who clears it need not be the same person. Nothing documented records who approved what, and the failure looks like a change nobody remembers agreeing to.

The convenience is real and that is exactly why it will be used this way. What it does right is keeping everything on your own daemon rather than a vendor's, so the record you wish existed could at least be built from files you already hold.

1. Persistent agent memory is usually a vector store nobody can read. Writing sessions and knowledge as JSONL and Markdown makes the context an inspectable artefact: a researcher can diff it, grep it and say precisely what the agent was carrying when it answered. 2. That property is worth more than any retrieval trick.

2. What is not described is selection: how much of a Mate's accumulated memory enters a given prompt, and on what basis. An inspectable store with an undocumented retrieval policy is legible at rest and opaque in use. No evaluation of the memory's effect on output is published, and none is claimed.

Multi-user is the feature that would normally carry a price, and here it is given away with no hosted option beside it. That is a decision, not an oversight, and it removes every mechanism a company would use to fund the support burden that multi-user software creates. Moat: none, though shared state does raise the cost of walking away.

Likely path: a hosted tier appears the moment the maintainer wants to eat, or the project stays a gift and grows slowly. Position: run it, and remember that the person answering your issue is doing it for free.

This is the first tool on the shelf that is actually multi-user. A shared workspace needs identity, and there is no single sign-on, no directory sync and no audit export, so membership is whatever the daemon's own configuration says it is. Sixty people through one door with no directory behind it is a finding, not a rollout.

The finance side is free and the hosting side is ours: a daemon on a machine we run, backed up and patched by us. Approved with conditions: it goes behind our own identity proxy, scoped to one team rather than the estate, until there is a directory integration to review.

Managing MCP servers once for every runtime it hosts is the practical win. Ten CLIs would otherwise mean ten config files drifting apart; here the servers are attached in one place and the agents inherit them. That is the kind of chore removal I will trade a daemon for.

MIT means the daemon is mine to read and fork, and self-hosting means nothing about the work leaves my hardware. It runs no model of its own, so the weights question belongs to whichever CLI I point it at. Grudging respect for a project that solved the boring problem instead of adding another agent.