Zleap-Agent

The deciding trait is that context is partitioned rather than accumulated. Each workspace carries its own instructions, tools and history, so the agent you use for one job does not arrive carrying everything it learned doing another. Anyone whose assistant has confidently applied last week's conventions to this week's project will understand why that is worth structuring.

The cost is setup: you define the workspaces, and the tool is only as good as that work. Pick it if you genuinely run several distinct kinds of task. Pick a single agent if you mostly do one.

Preview quality and unrestricted execution are a poor combination. The permission modes are two settings, and the permissive one removes the gate entirely for tools that reach the operating system and the shell, in code the authors are still telling you not to rely on. Nothing in the row describes isolation between that mode and the machine.

What it does right is label itself. An early preview declared as one is far better than the same maturity described as a release, and the two-mode permission model is at least explicit about which contract you chose.

1. Most context work in this field is retrieval: selecting from a large pool at query time. This argues for partitioning the pool itself, so irrelevant tools and memories are not candidates for selection at all. The distinction matters, because a retrieval error over a smaller set is a smaller error.

2. The rationale given, that this matters most for smaller models, is sound and testable: capacity to ignore distractors scales with model size. 3. No test is offered. The argument is well formed and unaccompanied by evidence.

An incorporated vendor publishing a preview under a permissive licence is buying attention before it has decided what to sell. The workspace positioning points at local and on-premises deployment, which is a real segment with real budgets and a long sales cycle nobody funds by accident.

Moat: none yet; the idea is a design pattern others can adopt in a release. Likely path: a commercial on-premises product with this as the open core, or nothing. Position: watch for the pricing page, which is when this becomes a decision.

A relational store underneath the memory changes what is possible. Backups, retention rules and queries against what an agent recorded all become ordinary operational work rather than a feature request, and the approval-required mode gives me a setting I can mandate rather than a habit I have to teach.

What is absent is identity: no directory integration, no provisioning, and no central console across sixty installations. Nothing runs inside our delivery process either. Approved with conditions: approval mode enforced, the database on our infrastructure, and one team accountable.

Building the whole design around smaller local models is the rarest thing here. Most projects treat a local endpoint as a compatibility checkbox; this one treats limited context as the constraint worth designing for, which is what actually makes my own weights usable. MCP servers attach alongside the built-in tools, so what I already run is available.

A permissive licence keeps the fork mine. The missing install path means I read the source to work out how to start it, which I will do and most people will not.