El Crítico

The project promotes security. The documentation describes sandboxed execution via Docker or Apple Containers. The recommended installation, however, uses curl | sh. This method requires trust in the server and the connection. An engineer concerned with security would not use it.

The project avoids a plugin marketplace, which it frames as a defense against supply-chain attacks. It is a local-first server built in Rust. It offers a wide range of documented integrations and a comprehensive security model.

Onlook targets teams where designers modify production interfaces directly. The workflow combines visual DOM manipulation with direct two-way code synchronization. It runs projects inside web containers and relies on OpenRouter models. The constraint is the stack. The visual editor assumes Next.js and TailwindCSS. If your application relies on alternative styling systems or component architectures, this synchronization cannot function.

The trade-off centers on model configuration and governance. While the core codebase is open-source under Apache-2.0, you lack support for local models or custom API keys. Teams requiring strict local-only execution or bespoke model endpoints must evaluate whether this architecture meets internal compliance rules.

The risk is fragmentation. The core is one distribution, the protocol support arrives as an extra on a slim variant, and memory, sub-agents, context compaction and a full coding agent live in a second package. Three release cadences behind one advertised product is a version matrix you inherit, and a break across that seam costs you an afternoon of bisecting somebody else's dependency graph.

Pin them together and read both changelogs as one. Done right: durability is delegated rather than reinvented. Long-running work is handed to Temporal, DBOS or Prefect, systems that already survived production, instead of a retry loop written by an agent library.

Flue is useful for TypeScript developers who need stateful background agents. The framework abstracts model execution, MCP tool calls, and durable state into a declarative hook model. State persists across server restarts through recorded session streams. However, configuring execution requires caution. Running useSandbox(local()) grants filesystem access without container isolation. The architecture depends entirely on external API keys and brings no built-in terminal or browser.

Adopting Flue requires committing your workflows to its custom runtime abstractions. The open-source model keeps entry free, but unconstrained multi-agent delegation risks uncontrolled API token consumption during autonomous loops.

The name is a misnomer. Qwen Audio Agent does not perform work. It is a voice runtime that connects to backend agents which perform the work. The documentation states it connects to agents like OpenCode or custom adapters. The runtime itself lacks terminal, browser, or file system capabilities. Its purpose is to prevent a voice interface from blocking while a separate, connected agent completes a task.

This separation is its main architectural strength. It also means any execution failures belong to the backend agent you connect. The cost is free, but you must bring your own API keys for the backend models. It provides a full-duplex voice layer for other tools.

The risk is a soft dependency. The graph runtime stands alone. The moment an agent needs a local model it imports ChatOllama from LangChain, and the moment it needs MCP tools it installs langchain[mcp], so the dependency you were told you did not need is the one that ships the tools. Version drift between the two lands on you.

The consequence: pin both packages together and treat a LangChain release as a LangGraph release. First-party MCP and Ollama adapters inside langgraph itself would change this verdict. What it does right: human-in-the-loop lets you inspect and change state at a checkpoint before a bad step lands.

The design decision that makes this pleasant is also the one that removes your safety margin. The loop runs in your process rather than on managed infrastructure, command execution is a listed capability, and no isolation layer appears in the documentation. Whatever credentials that process holds, the agent effectively holds, and a service account is usually generous.

Run agent workloads under a separate identity with its own scoped permissions. What it does right: execution limits are a first-class feature, so a loop that will not terminate is stopped by the framework rather than by your billing alert.

The risk is that changes become invisible. Logic assembled visually lives in the platform's own storage, not in files a reviewer reads, so the question of who altered a production prompt last Tuesday has no answer of the kind engineering has relied on for thirty years. Rollback and staging become platform features rather than properties of your existing process.

Decide how changes are reviewed before non-engineers start making them. What it does right: a marketplace of providers and tools means the integration surface is not gated on the maintainers' time.

The risk is that there is no isolation: a wrong lint or test command runs where you are standing, with your credentials in scope. That is the same exposure as running the command yourself: the tool is exactly as dangerous as the commands you allow it.

The mitigation is designed in. Every change is a git commit, so a corrupted edit is one revert and a bad session is a range you can drop. That is the right trade for a tool that shows you everything. What it gets right beyond that: the docs describe every flag, so there are no surprises.

The risk is the dependency matrix. The library is three layers: langchain-core, langchain, and a provider package per vendor pulled in as an extra such as langchain[anthropic]. Every one of those moves on its own schedule. A lock file that worked in spring resolves differently in autumn, and the error surfaces inside a tool call rather than at import.

The consequence: pin every layer and treat provider packages as part of your own release. What it does right is create_agent's small signature. The harness is minimal by design, so when something breaks, the surface you are debugging is the middleware you wrote, not a thousand lines of chain.

The --fix flag is the part to think about. The same system that decided something was wrong then writes the correction and applies it, with no independent check between the finding and the change. A false positive stops being a comment you dismiss and becomes a commit you have to notice.

There is a second concern in the same place: findings arrive as suggested fixes on a pull request, which is exactly the format people accept without reading. What it does right is the reporting path. Everything lands in Checks, so a review that ran and found nothing is distinguishable from one that never ran.

The risk is that local-first means unprotected by default. Code executes in the environment you launched from, with no container in the capability list, so the same property that makes it useful over ssh makes a mistaken command a real event on a real host. On a shared server that is somebody else's problem too.

Run it as a user with the permissions the task needs and nothing more. What it does right: it commits automatically, so the state before a bad turn is recoverable with git rather than with memory, and pre-commit integration means the project's own checks run against what it wrote.

Codex CLI sandboxes commands, sandbox_mode running from read-only to danger-full-access, but the mode is chosen once and forgotten, so the permissive setting a user picks on day three lets a bad command run on the machine. The API-key path bills per token, which lets a loop run until you notice; the Plus path rate-limits instead, which starves a long task but never surprises the card. Two failure modes, one for each way to pay.

Keep the restrictive level in a repo that matters. What it does right: codex exec is a real headless mode, so the same agent can be bounded by a script and a timeout in CI.

The risk is isolation. The tools doc lists write_file, delete_path and a terminal tool, and sandboxing is opt-in, applied only "when Zed Agent sandboxing is enabled"; even then the fetch tool sits outside it, so a prompt injection that arrives through a fetched page runs with the agent's full reach. A bad rm runs where you are standing, and the default is standing in your checkout.

Turn sandboxing on before the first session and treat fetched content as hostile. What it does right: every tool call asks for permission before it runs, and the permission model is explicit in the docs rather than implied by a demo.

The risk is the absence of a sandbox. Commands run with your user's permissions in the checkout you are editing; a bad rm in a generated script is a bad rm that ran on your machine, and there is no container layer to absorb it. The failure mode is common among terminal agents, and no less serious for it.

The safe configuration is yours to build: a container, a throwaway worktree, or a permission prompt you refuse to click through. What it does right: opencode run is a non-interactive mode, so the agent can be wrapped in scripts you control and killed by a timeout you set.

The worst thing is the meter, and it is your meter. A run that loops on a failing test bills every attempt, and billing at cost is not the same as a cap; nothing in the product stops a bad afternoon from costing what a good week would. Autonomy reads until it stops, and you pay for the reading.

The consequence is that a budget alarm belongs in your provider console before the first run, not after the first invoice. What it does right: commands execute in a Docker sandbox, so a bad rm is a container's problem and your working tree is one volume mount away from safe.

The trade is stated plainly and it is still the wrong way round. Approval prompts are removed because a filter is expected to catch the harmful cases, which inverts the usual safety posture: instead of allowing what is known to be safe, it refuses what is known to be dangerous, and everything nobody enumerated runs without a prompt. Shell syntax is very good at not looking like itself.

What it does right is scope the servers. Restrictions can be applied per mode, so a debugging session does not inherit the tool list an architecture session needed.

Count the products. Conversations, in-place transformations, a prompt library, multi-step workflows, a review interaction and a bridge to half a dozen external agent binaries all live in one plugin maintained by one person. Each of those is a reasonable project on its own, and together they are more integration points than any single maintainer can regression-test, so breakage arrives in the corner you happen to use.

What it does right: the review interaction requires you to approve or reject each change, so the most dangerous feature is the one guarded most explicitly.

The gap is between brand and behaviour. Tool servers can be run as containers, and the row records that the shell tool executes arbitrary commands in the user's environment instead. Nobody reads that sentence before granting a toolset. Combine it with automatic delegation between agents and the command that ends up running was chosen by a component two hops from the file you wrote.

What it does right: the tool surface is declared in the same file as the agent, so what an agent may reach is reviewable in a diff rather than discovered in a log.

The exposure is the command tool. It sits alongside the file and search tools as a peer, which means the loop treats running something and reading something as the same kind of step, and nothing in the published material describes a container, a command allowlist or a dry run between a model's suggestion and your terminal. That is a decision, not an oversight.

What it does right is stay inside a process you already trust. The plugin runs where your project is already open, so the credentials and paths it can reach are the ones you brought.

Auto-approve is the setting to read twice. The extension serves the hosted agent's file reads and writes against your workspace and runs the commands it asks for, and the policy governing all of that is configurable, which means it can be configured wrongly once and then never thought about again. The failure is silent by design: approval is the only gate and you have turned it off.

The compensating design is that the extension does nothing on its own. It has no model and no loop; everything that goes wrong here was asked for by an agent you chose, which narrows the blame but does not stop the edit.

The platform markets itself as an open agentic coding platform. The documentation lists terminal execution, multi-file editing, and a Docker sandbox. It does not include a browser. This restricts the agent's problem-solving to the information already present in the local codebase or its training data. An agent cannot look up new libraries or error messages.

DeepCode is free and open-source, with a bring-your-own-model architecture. This avoids metered billing for runtime failures. It provides a shared runtime across a CLI and a desktop application, ensuring session consistency.

The agent cannot perform basic developer tasks. It does not have terminal execution, git operations, or multi-file editing capabilities. The documentation mentions a "layered sandbox" but the agent's inability to interact with a real development environment makes this a solution in search of a problem. A user cannot ask it to install a dependency or refactor code across a project.

This severely limits its use for software development. The marketing claims cost savings and Fable 5-level performance on research tasks. The tool is free and open-source, supporting local models and many providers. Its strength is cost management for supported tasks.

The risk is gravity. Gemini is the default, the documented MCP sample sets model="gemini-flash-latest", and everything else arrives through a LiteLLM adapter. Portable in principle, Google in every example, which means the first time a non-Gemini model misbehaves you are debugging an adapter nobody at Google runs in production.

The consequence for a team is that model portability is a claim to test on day one, not a feature to assume. Non-Gemini examples in the official docs would change this verdict. What it does right: an evaluation framework with custom metrics and user simulation ships with the toolkit, which most frameworks leave to the user.

The risk is asymmetric lock-in. The model can be replaced through a custom provider. The tools cannot: web search, file search, code interpreter, computer use, shell and apply-patch are hosted tools that run on OpenAI's platform and bill per call. Move the model and the agent keeps its brain but loses its hands.

The consequence is that portability has to be designed in from the first commit: local function tools for anything that touches your data, hosted tools only where nothing else exists. What it does right: guardrails are a first-class primitive at the input and output boundary, not an instruction buried in a prompt.

The Bash sandbox is off until you run /sandbox, and even on it leaves file tools and MCP servers unconstrained, so a bad rm does its damage in your real repository before you read it. Pay-as-you-go through an API key bills a subagent that spins for an hour for the hour, and it has no way to know it is spinning. Two meters, one on your disk and one on your card, and neither has a floor.

Give it a worktree and a spend alert on day one. What it does right is multi-file editing that lands as one coherent change, with hooks that make verification deterministic rather than optional.

Count what you are taking on. Workspaces declared as code need someone to maintain those definitions, a control plane needs upgrades and backups, a brokering layer sits in the path of every model call and becomes an outage when it fails, and all of that exists before a single line of code is written by an agent. Teams underestimate this consistently, and the failure is not a bug, it is an unstaffed rota.

What it does right: workspaces are network-isolated, so an agent that goes wrong is contained by the architecture rather than by a setting.

The architectural tension is inherited. This engine was designed for steps that either succeed or fail and retry the same way every time. An agent node breaks that contract: it can succeed differently on each run, and the documented mitigation is inserting a human approval step, which is a control that does not scale to a workflow firing hourly.

Instrument the agent node separately and alert on output shape, not just on errors. What it does right: workflows publish over MCP, so the platform becomes a tool provider for outside clients instead of a place things go in and never come out.

The trap is that two installs of the same version are not the same program. Install from the published package and the control helpers are present; build from source and they must already be on your path or configured, and the seccomp helper is a separate build step of its own. That means the protection an engineer thinks they have depends on a choice they made at install time and will not remember.

What it does right: writes are scoped to the workspace by default, so the ordinary case of an agent wandering out of the project directory is closed before any of this matters.

The gap is the default. Filesystem and shell backends are pluggable between local, sandboxed and remote, which is the correct architecture and also means the safe option is a choice rather than a starting point. A developer who wires this up quickly gets a shell tool pointed at the machine they are sitting at, and nothing in the row says that is unusual.

What it does right is delegation. Sub-agents receive tasks in separate context windows, so a long side quest does not poison the parent thread with its own transcript.

The risk is reviewability. What the builder produces is a serialised graph, and a serialised graph does not diff into anything a reviewer can reason about. Two engineers editing the same flow produce a conflict resolved by choosing a whole file. Approval degrades into opening the tool and eyeballing the picture, which is not a control.

Treat the flow file as a binary asset and put the review burden on a demo, not a diff. What it does right: any flow publishes as an API, so the canvas is a starting point rather than a dead end you have to rewrite.

The risk is the extension model. Extensions are TypeScript modules that add tools, commands, events and UI to the running agent, and packages bundle them for distribution, so installing one runs somebody's code inside the process that holds your API keys and your shell. There is no sandbox around an extension, only trust.

Read the package before you add it, and keep the list short. What it does right: the official install is npm install -g --ignore-scripts, which shows the author applying the same suspicion to npm that you should apply to extensions.

The coupling is the risk. A framework whose examples are refreshed to follow one vendor's releases is a framework whose regressions are found on that vendor's models first, and anything else you point it at is territory nobody is testing on your behalf. That is not lock-in by licence, it is lock-in by attention.

The second exposure is the interpreter, which writes and runs code by design. What it does right is scope the install: capabilities arrive as named extras, so a deployment that does not want execution simply does not ask for it.

The gap is the registry. Extension compatibility is real, but the catalogue it draws from is smaller and differently populated than the one most developers know, and several widely used extensions are absent or lag behind because their publishers do not target it. Nobody discovers this during a demo. They discover it on day three, when a required debugger is missing.

What it does right is naming the agents. Coder, Architect and the rest are separate documented units, so a user knows which one answered and can disable the ones they distrust.

The credential design is the flaw. Secrets are stored encrypted inside the repository that versions agent state, so every key ever used remains in history under a key that also has to live somewhere. Rotation does not remove the old value, a clone carries the whole archive, and the encryption is only as good as the one secret nobody rotated.

What it does right is give every agent its own container. Isolation is per agent rather than per installation, which is the correct granularity for a fleet.

The structural risk is that the specification lives somewhere else. Emulating another product's behaviour means the reference implementation belongs to a company with no interest in this one, so every interaction change upstream becomes either churn here or a growing gap. The installation also compiles native code through a build step in the plugin manager, which turns a plugin update into a toolchain problem on machines that lack one.

What it does right: project instruction files put the conventions in the repository, where every contributor sees them.

The concentration is the risk. Credentials for a thousand applications, held per end user, live with a third party so your agents can act without holding them. That is a real convenience and it also means a compromise or an outage there is not degraded service, it is total loss of every connected capability simultaneously, and a credential rotation you would have to explain to your own customers.

Ask for the incident history and the isolation model before designing around it. What it does right: tool execution happens in a sandbox rather than in the calling process.

The coupling is worth naming. Connections to the agent frameworks it lists run over a protocol this team wrote, which is presented as an open standard and is currently a house format with adopters rather than a specification with competing implementations. If the sponsor's priorities move, the standard moves, and every framework integration that depends on it moves too.

Treat the protocol as a vendor interface until a second implementation exists. What it does right: human approval is a first-class step in the run rather than something each application reinvents at the last minute.

The integration is the risk. A configuration step wires this into the shell that runs every command on the machine, and the same program executes commands against your working tree with no container between it and the filesystem. Two capabilities that would each deserve scrutiny separately are combined in the process you use most.

Read what the setup step changes before running it, and keep it off machines with production credentials. What it does right: it performs git operations, so its work arrives as commits that can be inspected and reverted rather than as anonymous edits.

Two claims here need a noun. Containment is asserted without saying what performs it, so a reader cannot tell whether a stray command is stopped by the kernel, by a wrapper, or by a prompt. And the confirmation gate is both optional and partial, which means the set of actions that proceed without asking is decided by the tool rather than by the operator.

What it does right is delegation with evidence. Subagents return findings the coordinator can check rather than summaries it must trust, which is the correct shape for parallel work.

The observability story leans outward. Debugging and monitoring are provided through an integration with a separate commercial service, which means the trace you need at two in the morning lives somewhere with its own pricing, its own availability and its own retention. Nothing in the row describes what remains visible if that connection is absent.

What it does right is cover the whole lifecycle in one place. Retrieval, tools, workflows and orchestration are one dependency rather than four with mismatched conventions.

One daemon carries everything. The desktop app, the web interface and the command line all read the same background process, which is elegant until it stops. Nothing in the row describes what happens to an in-flight session when that process dies, whether state survives a restart, or how a client behaves while it is gone.

The compensating design is real. Because there is one process rather than four, the surfaces cannot disagree about what a session is doing, which removes the class of bug where two views show different truths. That property is worth the risk it creates.

Worktrees isolate files and nothing else. Several agents running at once against the same project still share one machine, one port range, one package cache and one set of build outputs, and the row documents no container around any of them. Two panes running a dev server is the first collision, and it is not the interesting one.

The honest part is that it says what it is: a terminal manager for agents that already exist, with no claim to sandboxing them. What it does right is the diff viewer sitting next to the agent, so reviewing what a pane did is one tab away rather than another tool.

A pre-1.0 version number on a foundational layer is a promise that something will move. The published commands pin a minor series rather than a major one, which is prudent and also an admission: upgrades in this range are permitted to break, and the thing being upgraded sits between your product and every agent it drives.

What it does right is putting the version in the instructions rather than telling you to install the latest and discover the change during an incident.

The omissions are deliberate and the users will not be. There is no isolation layer and no commit boundary in the row, which is the right call for something written to be legible, and it means an agent that edits files and runs commands hands you no way back. Nothing in the packaging distinguishes a study object from a daily driver at the moment of installation.

What it does right is keep durable sessions on disk, so the record of a run survives the terminal that produced it.

The workaround is the problem. One of the CLIs it drives blocks protocol tools in its non-interactive mode, and the stated remedy is a flag whose name says what it does. A review tool that requires approvals and the protections around them to be turned off in order to run automatically has inverted its own purpose.

The row records this plainly: a documented hazard is still a hazard, and the flag will be pasted into a pipeline by someone who did not read the sentence around it. What it does right is naming the limitation instead of leaving it to be discovered in a failing job.

The supervision is second-hand. Five different agent runners can be launched, each with its own idea of what working looks like, and the orchestrator detects a stall and recovers an orphan by watching from outside. A runner that is thinking slowly and a runner that has hung present the same way. Recovery then reclaims work that was not actually lost.

What it does right is refuse to guess about dependencies. An issue whose blockers are unresolved is skipped rather than attempted, which is the correct default and one most schedulers get wrong.

There is no containment. The tool executes commands and operates on your repository, and the row records no sandbox, no container option and no confinement to a directory, which means the limit on a mistake is the limit on your own account. The tagline says secure. The specification does not say what that word is doing.

What it does right is keep git in scope. Because it performs the operations itself, a session leaves a history rather than a pile of unexplained modifications.

The risk is calling a worktree a boundary. Several runs execute at once, each in its own checkout, and no container sits between them and the host. A command that touches a shared service, a global package cache or an environment variable reaches every other run and the developer machine underneath. Docker isolation is not part of the design.

Run it on a dedicated box with credentials scoped to what a run may touch. What it does right: bash, tests and git operations execute as deterministic nodes rather than as model output, so the parts a computer does reliably are not delegated to a language model.

Defaults decide outcomes. Three execution modes exist and the one that requires no extra package is the one that runs model-written code directly against your filesystem, which means the least careful setup is also the most common one. Anyone following the quickstart has already made that choice without being asked to.

What it does right is offering the other two at all, and documenting which extra brings each of them. The isolation is a package away rather than a fork away, which is the correct distance.

Per-folder trust has no documented expiry. A directory you promoted during one easy afternoon stays promoted, and nothing in the row describes revoking it, reviewing what is currently trusted, or prompting again when the task changes. The permission model is only as good as your memory of it.

There is no git integration either, so the recovery path after a bad full-access run is whatever you set up yourself. What it gets right is cancellation: stopping a turn stops the subagent tree beneath it, which is more than most tools with subagents can claim when you press the key.

The precision is language-shaped. Symbol resolution runs through Go's own type checker, which is why callers, interface implementations and impact analysis are trustworthy there. In every other language the row records that the general tools take over, so one feature name covers two very different qualities of answer.

That gap will not announce itself. A user in a TypeScript repository gets an answer from the same command and no signal that it came from a search rather than a type checker. What it does right is naming the mechanism at all, so the boundary is discoverable by anyone who reads.

Responsibility is split at the worst point. The tool creates the worktree and reports on push state and pull-request checks, and the agent is expected to open the pull request. When that does not happen, the display shows an absence rather than an error, and an absence is easy to read as not finished yet. Work sits complete and unmerged for a day.

What it does right is let you run the project inside the worktree, so a change can be tried rather than only read.

The risk is breadth per maintainer. This project predates the category by a decade and now carries service discovery, RPC, pub/sub, a key-value store, a typed model layer, durable flows, an agent loop and a per-call payment standard. Commercial support is offered directly by the maintainer, which is honest and also tells you how many people are behind all of it.

Depend on the parts you can read. What it does right: the guardrails are concrete rather than aspirational, with a step ceiling, a repeated no-progress limit, and an approval hook for human sign-off before a tool runs.

The boundary is editable by the thing it bounds. When the agent needs a tool it does not have, it writes a Dockerfile and rebuilds, which is elegant and puts the definition of the enclosure in the same hands as the code inside it. The row scopes those files per project and says nothing about what they may contain.

A mount, a network flag or a privileged directive is one line, and nothing documented reviews these files before they are built. What it does right is scoping them per project, so the blast radius of a bad one is a single working directory rather than a machine.

The unanswered case is the network. Work can be dispatched to a remote host you already have access to, which is genuinely useful and introduces a failure mode the local design never had. Nothing states whether a dropped connection kills the session, orphans it, or leaves it running unattended on a machine nobody is watching.

The third of those is the expensive one, because an orphaned agent keeps spending. What it does right is worktrees: parallel sessions on separate checkouts means the concurrency problem is handled by version control rather than by hoping two agents avoid each other.

Trellis runs agents with local terminal access. The documentation does not specify a sandbox. This architecture means a misconfigured or malicious agent could execute arbitrary commands on the host machine. It has the ability to perform git operations, which introduces the risk of a corrupted repository state if an operation fails or is interrupted.

Trellis's value is providing a shared context layer for multiple coding tools. It persists project specifications and memory inside the repository, allowing different agents to work from a consistent set of requirements. This makes it a useful harness for teams standardizing AI workflows across developers.

Read the recovery features as a defect list, because that is how they were written. Processes go missing. Containers disappear while a run is mid-flight. Teardown arrives before the useful output has been captured. Every one of those has happened enough times to justify a component, and the components mitigate rather than prevent, so the underlying instability is still there.

What it does right is naming them in public. Most projects handle this quietly and let users discover the gap during their own incident.

Emdash claims to be an "agentic development environment." The architecture uses Git worktrees to isolate parallel tasks, which is clever. It does not use a container or sandbox. This means every agent has direct terminal access to the host filesystem. A misconfigured or malicious agent action is not contained.

The tool provides a structure for running multiple agents against a codebase. It integrates with issue trackers and supports remote machines over SSH. This is useful. The lack of a sandbox is a dealbreaker for any environment where security is a consideration.

The risk is merge semantics deciding what the model sees. A shared document type resolves concurrent edits automatically, by rules designed for prose rather than for a prompt, and nobody reviews the resolution. Two people trimming context at the same time get a result neither of them wrote.

Nothing in the documentation describes conflict handling for that case, and the failure is silent, which is the category of bug that ends up blamed on the model. What it does right is keeping the session on disk rather than in a service, so the record outlives the client that created it.

The risk is diffuse ownership of the failure. When an agent will not start, the cause is a key, a checkout, a session or a daemon, and the diagnosis lives in four different logs written by four different programs with no correlation between them. Nothing documented ties them together.

That is the cost of building on a boring stack rather than a service, and it bites when the number of agents is large enough for something to be broken at all times. What it does right is refusing to run a managed service, so there is no fifth failure stacked on top of the four.

The risk is split. The cloud coding agent is isolated in an ephemeral Actions environment, but it is metered as premium requests, so the safer path is the one that upsells you. Local agent mode edits and runs commands on your machine outside that sandbox, so a wrong command lands on your laptop.

The consequence is that teams on the base plan will run the unsafe mode by default and discover the safe one when the bill arrives. Ship the isolation to the local mode and this verdict changes. What it does right: the cloud agent returns a pull request, so nothing lands on a branch without a human review.

The risk is a single vendor at every layer. No bring-your-own model, no local models, Claude and only Claude. Both packages ship a native Claude Code binary underneath the Python or TypeScript surface, so the loop you depend on is not the code you installed, and a behavior change in the binary is a behavior change in your product without a diff you can read.

Pin versions and test the binary like a dependency, not a library. What it does right: permissions decide which tools run automatically and which wait for approval, so the blast radius is a setting you own.

The risk is the default. The sandboxing page sets agents.defaults.sandbox.mode to off, so a fresh install runs exec, write and edit on the host with the user's permissions. Turn it on and the same page says it is not a perfect security boundary and that bind mounts bypass it, which is where most people put the repository.

Read the page before the first run, not after. What it does right: with the sandbox on, the network defaults to none and mounts from ~/.ssh, /etc and the Docker socket are refused, so the blast radius is small if you accept the defaults.

The risk is the session. The README documents reusing your existing Chrome profile with saved logins, and the cloud's MCP server exposes list_browser_profiles alongside run_session, so an authenticated profile is one tool call away from any client that holds the API key. A page with hostile text in it now talks to an agent that is logged in as you. No document on the site describes an injection defence.

The consequence: run it in a throwaway profile, and give the cloud a fresh account, not your own. What it does right is stop_session: a task can be killed mid-run from the same client that started it.

The failure mode is fatigue. Cline asks before every action, the right default, which users eventually replace with auto-approve; the MCP settings schema has an autoApprove list built in, so the escape hatch ships with the product. Once you take it, there is no Docker sandbox, and a wrong command runs with your credentials in your checkout, the same as any other terminal agent minus the illusion.

Auto-approve reads and searches, never writes and shells. What it does right is transparency: Apache-2.0 source and readable prompts, so when it misbehaves you can find out why.

The Agent's sandbox comes with the run mode: Auto-review sandboxes commands through Seatbelt or Landlock, and Run Everything hands them your machine, the checkout you were editing, and your credentials. The pricing page is the second failure mode: the tiers multiply Agent limits by factors the page never defines, so you cannot know what a limit is worth until you have spent it, and the upgrade prompt arrives at the worst moment.

Keep auto-run off outside a worktree and set a budget before the first month. What it does right is Tab and multi-file edit, still the reference the others copy, and the reason the bill gets paid.

goose's Docker sandbox is opt-in: pass --container and extensions execute inside an existing container, forget it and a bad command lands on a real filesystem with the user's permissions. A Linux Foundation home means no vendor to abandon it and no vendor obligated to fix it on a schedule, so a bug you hit waits for a volunteer.

The consequence: turn sandbox mode on before the first run and expect to read the issue tracker yourself. Sandbox by default would change the reliability score. What it does right: the source is open and extensions are plain MCP servers, so the fix you need is one you can write.

Look at what the protection depends on. Tool commands execute inside a container that requires a working local engine, and network restriction is applied by a proxy sitting beside it. Both are correct designs and both fail open in the ordinary ways: an engine that is not running, a policy that was never set, a proxy that is bypassed by a tool speaking a protocol it does not inspect. The dependency chain is longer than the marketing implies.

What it does right: web search and fetch are documented as what they are, and the row records no browser automation rather than implying it.

The risk is a checkbox. Command execution has a setting to run shell commands or run configurations without confirmation, called brave mode, and once on, terminal calls are unattended. The MCP page describes no per-call approval model, so a server you added for one task answers every task after it.

The consequence: treat brave mode as a per-project decision and keep it off in any repository with deploy scripts. Per-call approval for MCP tools would change this verdict. What it does right: database tools are held to a read-only database user, so the agent cannot drop a table by accident.

The failure mode is screen scraping. Keystrokes go in, rendered terminal output is read back out as structure, and that works exactly as long as the rendering is stable. The agents being wrapped ship weekly and none of them owes this project a stable presentation layer. When the parse slips, what comes back is well-formed and wrong, which costs more to detect than an outright error.

What it does right is scope. File editing, git operations and isolation are all recorded as belonging to the wrapped agent, not to this. It relays and it does not pretend otherwise.

The failure mode is a setting. Session modes run from asking every time, through a configurable allowlist, to bypass, and the third option exists because someone found the first two tedious. On a tool with terminal execution and multi-file writes, the tedious options are the safety model, and a per-session toggle is the kind of control that gets flipped once and never flipped back.

What it does right: Plan Mode changes no files until the plan is approved, which separates the expensive mistake from the cheap one.

The risk is blast radius. Terminal execution and repository writes are both recorded on this row, and no container boundary of its own is. Whatever confinement exists is inherited from the execution context, which in a DevOps platform is the context that already reaches production. A prompt that goes wrong here does not stop at a working copy.

What it does right is naming things. Work is expressed as flows built from a published catalog of agents rather than one open-ended assistant, so what a run is allowed to attempt is declared in advance and can be argued about before it executes.

The concern is co-location. An in-app browser that agents can drive shares a process boundary with the workspaces holding your remote connections, and the row records no container isolation of any kind. Content fetched by an agent is untrusted input; here it arrives inside the tool rather than beside it. Nothing documented explains what the browser may reach or what it may not.

What it does right is refuse a lie of convenience: the sidebar reports branch and pull request status while the application performs no git operations itself, so a display never implies an action it did not take.

The risk is that simplicity is a policy. The docs say that for tasks like opening PRs you tell the LM to figure it out, so the model improvises where other harnesses have a procedure, and improvisation is where the wrong git command lives. Without an environment flag, commands land on your machine.

The consequence: never run it outside a container on a repository you care about, and expect the model, not the harness, to decide how a task ends. A documented procedure for the common endings would change this verdict. What it does right: Docker, Podman, Singularity, Bubblewrap and Modal are all first-class sandboxes.

The risk is churn. The project was phidata, then Agno, then Agno plus an AgentOS runtime with fifty-plus endpoints, SSE and websockets to keep stable. Every repositioning moves the API under the people who adopted the previous one, and a runtime that promises durable execution and distributed state has far more surface to break than an SDK. The changelog is the only record of what moved.

The consequence: pin versions and read that changelog before every bump. What it does right: human approval is a first-class primitive, so a run pauses for confirmation and tools that need an admin can be blocked rather than trusted.

The risk is surface area against maintainer count. Thirty-plus providers, two MCP directions, profiles, subagents and an API is a matrix no small team tests exhaustively, and the row confirms containers are documented for running the app rather than for confining the agent. Shell commands therefore execute in your own environment. Isolation protects your files and not your machine, and those are different guarantees.

Done right: nothing lands unseen. Proposed changes are gated behind a diff review and a tool-approval prompt, so the dangerous default is opt-in rather than assumed.

The loop is open by construction. An agent that writes code without a way to execute it cannot discover that an import is wrong, a signature changed or a suite went red; it can only propose and wait. Every correction therefore costs a full human round trip, and the failure mode is not dramatic, it is slow.

What it does right is the subagent arrangement. Different agents carry different models, tools and behaviour, so a cheap one can answer questions while an expensive one edits, and the user knows which answered.

The failure mode is blast radius. The capability list confirms command execution and repository operations, and lists no container isolation of any kind. That combination means a mistaken deletion or a bad rebase happens in your actual checkout, not in a copy. The documentation describes what it can do and does not describe what stops it.

Work on a branch you can throw away and keep the repository clean before each session. The one thing done right: it implements the Agent Client Protocol, so it plugs into Zed and JetBrains instead of demanding that its own interface become your editor.

Look at the permission surface. This thing drives the browser, the terminal, desktop applications, the filesystem and remote workspaces. Desktop application control is the widest grant on this board and it appears here beside no isolation layer at all, on a machine that also holds your email client. The failure mode is not exotic. It is one confident wrong action with reach.

What it does right is commit. Work lands in a real repository with real history, so the record of what happened survives the session that produced it.

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.

The headline says it tops a code review benchmark. The same post reports that on that benchmark about half the findings are not real bugs, which is the number that matters for a reviewer, because every false comment costs a human a minute and a little trust. One-click fixes with no Docker sandbox means the reviewer writes code, and a reviewer that is wrong half the time needs a reviewer.

Leave one-click fixes off for anyone junior and treat comments as prompts, not verdicts. What it does right is reach: four Git hosts and free public repos, so the noise at least arrives everywhere.

The risk is the environment. The docs have you configure dependencies, environment variables and secrets per repository and then set an internet access policy, so a task with the wrong policy is a process holding your credentials on an open network, running code a model wrote. The policy is set once, by whoever set up the repo, and forgotten by everyone who delegates a task afterward.

Use scoped tokens in the environment, never your own, and default the network to off. What it does right: every task gets a dedicated environment, so one bad run does not contaminate the next.

The risk is the folder named ee. The repository is dual-licensed by directory, and the example the README gives of an enterprise directory is packages/core/src/auth/ee/. Authentication is not an add-on; it is what stands between a demo and a deployment, and the code for it may be used freely for development and testing but needs a licence in production. Teams discover this when they cannot avoid it.

The consequence: read LICENSE.md's mapping before the first commit, and decide whether your auth lives in the framework or beside it. What it does right: the repository runs CodeQL scanning in CI and publishes a security contact, which is unglamorous and rare.

Read the word passive. Contracts, the ledger and the safer execution mode ship switched off, which means the install most people run is the one without them, and the feature list describes a configuration nobody is in. This is the pattern where a product is safe in the specification and permissive in practice, and the gap is discovered by the first person who did not read the page.

What it does right is refuse outbound requests to loopback and private hosts by default. One control is on, and it is the correct one.

The limitation is stated plainly and it is severe for the buyers most likely to want this. Organisations running their own code host, which tend to be the regulated ones with the largest error volumes, get the analysis and not the automated change, because the integration reaches only the hosted editions. That turns the headline capability into a feature half the market cannot buy.

What it does right is delegation. It can hand implementation to an external coding agent instead of insisting on being the one that writes the patch.

The learning loop is the thing to watch. Rules are synthesised from your merged history, which means the system learns what your team approved, not what your team should have approved. Every convention you have tolerated becomes a rule that argues for itself, and nothing in the row describes a human gate on rule promotion or a way to expire one.

Reviews are advisory, so the damage is slow rather than acute: bad rules cost attention, not a broken build. What it does right is scope. It reads and comments and never edits, so the worst outcome is a comment you disagree with.

A server is a server. This one listens locally, manages provider logins and keys through the browser, and can upload files into your project, and nothing in the row describes an authentication step in front of any of it. On a laptop at home that is fine. On a shared machine, a conference network or a misconfigured interface, it is an unauthenticated key manager.

What it does right is avoid a second copy of the truth. Configuration and history are the files the agent itself uses, not a duplicate that can disagree.

The failure mode is convergence. Six agents in six worktrees produce six branches, and the manager stops at the point where they have to become one commit history. Nothing in the row describes conflict handling, ordering, or a merge queue. The work that parallelism creates lands on you, serially, after the fast part is over.

What it does right is refuse to invent a protocol. It drives the vendor CLIs as they ship, so a session behaves the way that agent behaves elsewhere and there is no translation layer to blame.

The risk is the interface, not the code. Worktrees are created, merged and deleted from inside the app, so destructive git operations become shortcuts in a screen where you are also switching contexts under time pressure. Nothing on the row describes a confirmation step or a recovery path. The failure is not a crash. It is a merge you did not mean to run and a branch you had not finished reading.

What it does right: documented devcontainer integration runs a session inside a container, so the agent's blast radius is a decision rather than a default.

The documentation says it plainly: the command tool is arbitrary code execution as the user running the server. That is the correct disclosure and it is also the problem, because the notebook process usually holds credentials, mounted data and network reach that nobody granted an agent on purpose. There is no isolation layer in the row, so the blast radius is the account.

What it does right is confine file access to the Jupyter root. Editing cannot wander outside the tree, which bounds one class of accident.

The confusion is between an instrument and an intervention. Parallel execution and speculative branching alter the order and the count of the steps a graph performs, which means results obtained with the accelerators enabled are not results from the system you shipped. Nothing documented forces a user to notice that distinction, and a profiler that silently changes the subject is worse than no profiler.

What it does right is separability. This sits beside the framework rather than inside it, so removing it restores the original behaviour exactly.

Being a coordination layer means inheriting somebody else's failures. Work is executed by external runtimes the project does not control, so when a run goes wrong the diagnosis lives in a tool that knows nothing about this one's goals, issues or reviews. The row also records no git operations, so the loop it draws around assignment and review does not close on a commit.

What it does right is separate the layers plainly, and say so, rather than pretending to be the runtime.

The risk is inconsistency. The docs say the status check can prevent merges, then note that GitLab does not receive status checks, so one configuration yields two policies: a gate on one host and a comment on the other, and a mixed shop discovers which is which when something merges that should not have. The failure mode is quiet by construction.

Treat the check as advisory everywhere until the GitLab side matches. What it does right: drafts, dependency-bot pull requests and packaging-only changes are skipped by default, so the bot does not spend its credibility on noise.

The isolation is at the wrong granularity. The system is deployed as containers, and nothing documented gives an individual task its own boundary, which means several agents running at once share whatever the deployment can reach, including the shell and the repository. Scoped grants govern what an agent is allowed to ask for. They do not govern what a process can touch.

What it does right is version the workspace, so a confused run leaves a trail that can be unwound.

The isolation is asymmetric. Shell commands run inside a virtual machine, which is a real boundary, and the headline capability drives the desktop applications on the host, which is outside it. So the strongest containment protects the weakest capability, and the feature that clicks buttons in your signed-in applications answers to nothing but the model.

What it gets right is stating the boundary. The documentation says which mechanism applies on which platform, so a careful reader can work out what is protected without guessing.

The risk is the write path. Reviews are read-only, but background agents grant the app write access so Claude Code can push fix commits and open pull requests, and a reviewer that can write is a second author with your app's credentials. The privacy page limits that scope to fix branches and says main is never pushed directly, which is the right boundary and also a promise, not a permission you set.

Turn on background agents per repository, not per org, and read the branch protection rules first. What it does right: comments auto-resolve once the code addresses them, so the thread ends when the bug does.

The dependency is the whole design and it is not hidden. The runtime is one vendor's CLI, the model is that vendor's model, and there is no substitution recorded anywhere in the row. Code written against these SDKs is not portable in any sense that matters: not the tools, not the sessions, not the permission model.

That is a fair trade for a first-party SDK and an unfair surprise for anyone who reads framework and thinks abstraction. What it does right is refusing to pretend: nothing here is presented as vendor-neutral, and the row says so in three separate fields.

The packaging is the risk. A web server, a language runtime and a copy of the agent SDK are bundled inside the download, which makes installation easy and makes the version you run somebody else's decision. When the underlying agent ships a change, this application ships it later, or not, and the row records no update mechanism that would tell you which.

What it does right is show the working. Thinking, tool calls and compaction state are visible while a turn runs, rather than after it.

The tool stops one step short. Each task runs in its own directory with its own worker and its own verdict, and nothing here commits, merges or opens a pull request. A run that succeeds completely leaves a pile of separate results and a manual reconciliation job whose size grows with the thing you were trying to parallelise.

What it does right is retry with the evidence. A failed task is attempted again with the failure output supplied, which is the correct way to spend a second attempt.

The published version is 0.6.2 and the documented install pins a lower bound rather than an exact release. Before one-point-zero a minor bump is allowed to break you, and a lower bound accepts every one of them, so the default instruction in the README is the one that will wake somebody up. Pin the exact version instead.

Nothing else here is dangerous, because the runtime does not touch a shell, a repository or a file. The risk is entirely in the dependency, which is the correct place for it to be, and it is the risk everyone ignores until a build fails on a machine that is not theirs.

The unifying API is the selling point and the exposure. Boot times, snapshot semantics, clipboard behaviour, display handling and crash recovery all differ between a virtualised guest and a container, and code written against the shared surface will encounter those differences only in production, on whichever backend the customer chose. Debugging then requires knowing the layer the abstraction was hiding.

Pin one backend per workload and test against that one. What it does right: isolation is the default everywhere rather than a mode you remember to switch on, which for computer use is the only defensible posture.

The risk is that consistency is a goal rather than a guarantee. Python and C# share a repository; Go is a separate project with its own documentation, samples and issue tracker, and the main page sends you there twice rather than explaining the relationship. Feature parity across three implementations maintained on three schedules is a promise no framework has kept, and the first divergence lands on whichever team picked the smaller one.

Check parity before committing a language. What it does right: agents can be defined declaratively in a versioned file rather than assembled in code, which makes a configuration reviewable in the same pull request as everything else.

The containment is genuine and it constrains what the agent can usefully do. WebAssembly execution cannot reach the host directly, so the class of task this safely covers is computation rather than operations, and anything touching real infrastructure has to leave that boundary through a path the documentation does not fully describe. The guarantee is precise; its coverage is not.

What it does right is degradation. Model fallback is automatic, so a provider outage produces a slower answer rather than a failed workflow.

The risk is unbounded delegation. Tasks hand work to sub-tasks, which may hand it back, and the documentation describes the mechanism without describing a limit: no default depth ceiling, no spend guard, no documented detection for two agents that keep addressing each other. The cost of that loop is a provider invoice discovered later.

What it does right is optionality. The retrieval component is attached when needed rather than assumed, so a simple agent stays simple and does not drag a vector database into a script that never needed one.

The limitation is structural and deliberate. A declared graph is fixed before the first call, which is what makes parallel execution tractable, and it also means the system cannot take a path nobody drew. Work that branches on what the model finds has to be expressed as every branch, up front, or pushed inside a single node where none of the guarantees apply.

The second option is the one people will take, and it hollows out the design without anybody noticing. What it does right is being honest about the trade: this is a workflow engine, and workflow engines are supposed to be static.

The risk is blast radius. The design point is one local index covering mail, meetings, chat and past assistant conversations, and agents can be triggered by an incoming message or by a schedule, so something acts on content you have not read yet while holding access to everything you ever indexed. Untrusted text arriving by mail lands at precisely the wrong layer of that design.

Scope the account and the trigger before enabling anything unattended. Done right: the bundled browser is separate from your everyday one, so the assistant only holds sessions you deliberately signed into there. That is a boundary rather than a promise.

The unattended hours are the exposure. A resident process making infrastructure changes is only as safe as its own judgement about what deserves an interruption, and that threshold is set by a model. Everything it classifies as routine proceeds with nobody reading it, and the failures that matter in operations are usually the ones that looked routine.

What it does right is being explicit that a human is in the loop by exception. That is at least an honest description of the bargain, which is more than most autonomous products manage.

The agent runs inside the application's own process, and everything a user would complain about, model choice, compaction behaviour, cost accounting and session state, belongs to that upstream project rather than to this one. So a defect in the part people notice is filed somewhere else and fixed on somebody else's schedule, while the crash lands in this window.

What it gets right is scoping sessions. Each tab holds its own agent session, so one confused conversation does not contaminate the next.

It is published for one runtime. JSR and Deno are the documented install, and npm support is described as coming, which puts most of the TypeScript teams who would want this on the wrong side of the line today. A library's reach is its package manager, and this one has picked the smaller of the two by an order of magnitude.

There is no unattended mode and no second agent, so the failure surface is whatever your own application exposes. What it does right is being explicit about that boundary: the library takes a loop and stops, and the rest of the risk is yours by design.

The product markets itself as an 'agentic operating system' for 'autonomous AI agents.' The architecture provides no sandbox, no terminal execution, and no git operations. The Content Security Policy allows 'unsafe-eval' for dependencies. Session tokens are stored in localStorage, making them accessible to any script injection.

An agent framework without system-level tools cannot perform most software engineering tasks. The security model assumes a benign environment, which is a significant risk when running plugins or agent-generated code. It is a TypeScript framework for building multi-agent applications with a polished user interface.

The risk is the feature. A graph supporting retries and clarification loops can revisit a node indefinitely, and no default iteration ceiling, no recursion guard and no spend limit appear in the documentation. The termination argument is left to whoever wrote the conditions.

That is a reasonable position for a library and a bad surprise for a first-time user, because the failure is quiet. What it does right is refusing to hide the loop: a cycle is an edge somebody wrote down rather than a retry buried inside a framework, so the thing that will spin is visible in the code.

The gap is between the list and the footnote. Two providers carry an alpha label in the documentation, which means a user who picks one of them is running the least tested path in the product while believing they picked from a menu. Nobody reads the footnote during evaluation. They read it after a session behaves strangely.

What it does right is isolation. Every session gets its own worktree and its own branch, so a misbehaving agent damages a directory rather than the working tree you were using.

The headline ambition is scaling from one agent to a hundred, and the row describes no machinery for it. Roles, definitions of done and reviewers are things you write into a prompt, not things a runtime schedules, and nothing here mentions a queue, a supervisor or a way to stop the tenth agent when the ninth has already fixed the bug.

At one agent it is solid. At three the absence of git integration starts to matter, because every agent is editing the same checkout and there is nothing recording who touched what. Ambition is fine. This one is currently a document.

The risk is what open means here. The workspace, the version store, the preview loader, the per-application database and the model routing layer are each a proprietary service of one provider, and the code orchestrates them rather than abstracting them. You can read all of it, deploy all of it, and only into one place, so the exit is a rewrite of the platform rather than a migration.

Export your generated projects early and often. What it does right: shell access is disabled outright, so the agent's capabilities are an explicit list instead of an open-ended command line.

The claim needs reading carefully. Consistency is guaranteed for the agent's own state and for actions recorded in the log, which is genuinely hard and genuinely delivered. It is not guaranteed on the other side of a call to a service that has no idea it may be replayed.

Replay after a failure re-issues the action. If that action was an email, a payment or a support ticket, the log records one occurrence and the world records two. Nothing documented resolves that. What it does right is stating the guarantee precisely instead of selling the phrase and leaving the reader to assume the rest.

The failure mode is ordering. Conditions are evaluated top down and the first true one takes the run, so a broad condition placed above a narrow one swallows every case beneath it. Nothing warns you, and the run finishes looking exactly like a correct one. Debugging that means reading the file and simulating the expressions in your head.

Two guards bound the blast radius, and the documentation names both: a maximum iteration count and a timeout. Those stop a runaway. They do not stop a wrong answer, which is the more common outcome.

The problem arrives at the second contributor. A visual project is a file, and files get branched, conflicted and reviewed, but nobody reads a serialised node layout for intent. So changes are approved by opening the editor and comparing by eye, or approved without being read at all, and the second happens more often than teams admit.

What it does right is refusing the usual two-artefact trap, where you prototype visually and then rewrite the whole thing by hand for production.

The product claims to be a full-stack agentic engineering framework. The repository shows it cannot edit multiple files or perform git operations. It offers a terminal and a Docker sandbox, but its ability to act on a codebase is limited. It is a framework for building agents, not an agent for building software.

This makes it a tool for creating tool-using agents in a constrained environment, not an autonomous software engineer. The focus is on governance, multi-tenancy, and tool discovery via its MCP server implementation. It provides a solid foundation for building governed, tool-using agents for other tasks.

The risk is stated in the README, which is the candid version of a lock-in problem. One provider is supported on purpose. Every type, every event and every retry path is shaped by that decision, so a second vendor is not a configuration change, it is a parallel implementation with your name on it. Products outlive model contracts. That is where this bites.

What it does right is refusing to pretend otherwise. A narrow contract documented as narrow is easier to plan around than a wide one that leaks its assumptions at the edges.

The feedback loop is manual at its most important point. A reviewer marks a problem, then copies that text into a session and hopes the agent reads it in the context it was written about. Nothing carries the file, the line or the surrounding diff automatically, so precision depends on whoever is doing the copying, and precision is exactly what a correction needs.

What it does right is the escape hatch. A session that went wrong is deleted as a worktree, with no cleanup and nothing left behind in the branch you care about.

The risk is drift. Autonomous skill creation means the toolset in month three is not the one you installed in month one, and no review step is documented between a skill being written and being used. Run locally, the first execution option listed, those skills execute with your permissions. The documented Windows caveat that Defender flags the bundled uv.exe is a small thing, but it tells you how young the packaging is.

Pin the skills directory in git and read the diff weekly. What it does right: subagents are spawned isolated, so a parallel workstream cannot pollute the parent's context.

The risk is misrepresentation in the middle. Presenting capabilities a model does not natively have means the emulation's edges become the agent's bugs, and the agent cannot distinguish a model that answered badly from a shim that translated badly. Add automatic fallbacks and the run that failed may not have used the model you think it used. Debugging then involves three layers, only one of which you wrote.

What it does right: fallback models are an ordered list you declare, so degradation under a provider outage is a configured behaviour rather than an exception in your terminal.

The risk is that the abstraction is prose. Role, goal and backstory are strings; the framework composes them into prompts, and the behavior lives in the model's reading of those strings, so correctness depends on phrasing and model version in equal measure. Change a sentence, change the system; upgrade the model, change it again, and no test suite catches either.

Write evals before crews, and freeze the model version in production. What it does right: Flows persist state between start, listen and router steps, so the orchestration around the prose is deterministic code you can unit test.

The risk is a resident process without isolation. Daemon mode keeps the agent running between sessions, there is no container sandbox in the product, and every shell command lands in the checkout you are editing; a resident agent with a shell has your permissions and does not log out when you do.

Run it inside a container of your own or not at all in a repository you cannot rebuild. What it does right: configuration precedence is documented in order, CLI flags, then environment, then .env files, then settings.json, so when a setting wins you can say why.

The risk is the executor. The design is a model writing Python that is then run, and isolation is something you add: a CodeAgent without a configured sandbox runs generated code where you are standing, with your credentials in the environment. Code actions are more expressive than JSON tool calls, and more expressive means a wider blast radius when the model is wrong.

The sandbox argument is mandatory in anything that touches real data. What it does right: four sandbox backends are documented, Modal, Blaxel, E2B and Docker, so the safe path exists and is one constructor argument away.

The structural problem is that the contract is a command line. Grok CLI, Kimi CLI, OpenCode, PI CLI, OMP CLI and the DeepSeek Harness are carried in beta, and each one ships on its own schedule with its own flags and its own output format. A rename upstream is a broken panel here, and nothing in the design pins a version or degrades gracefully when the shape changes.

What it does right is scope the promise. Claude Code and Codex are the two that are not marked beta, and those are the two the plugin was built around.

Read the badge before the pitch. The project declares itself early development, commits continue, and no tagged release has appeared since August 2025, so anyone installing this is tracking a moving target with no version to name in an incident review. It also requires a working container engine and git on the host, which moves a dependency onto every machine that wants the protection.

What it does right is the failure path: a run you dislike is a branch and an environment you discard, and your own checkout was never a participant in the mistake.

The permission design puts everything on the invocation. Tools are gated, and the gate is lifted by a single flag on the same command line that starts the session, with per-tool allowances as the middle setting. Nothing sits behind that decision: the row records no sandboxing, and the documentation describes containers as a way to run the program rather than to confine it. One habit-forming flag is the entire boundary.

What it does right: a read-only plan mode exists as a real mode, so investigating a repository without any write path is a supported state and not a promise.

The flag is called --yolo. It disables the asking, and there is no Docker sandbox, so a headless run is an agent with your shell and nobody at the keyboard, running whatever the model decided a fix looked like. The name is honest, which is the only defense it has: nobody typed it by accident. Keep it interactive on anything that matters, and on anything else run it in a container you built.

What it does right is context: language servers feed the model diagnostics and symbols, so it reads the code the way the editor does rather than as text, and fewer of its guesses are wrong.

Strictness has a cost and it lands on the weaker model. Every edit requires an identifier the model has to emit exactly, and anything that drifts is refused, which means a session can burn turns retrying instead of failing over to something looser. The design is deliberate and it makes the tool's usefulness a function of the model behind it in a way a diff format does not.

What it does right is refuse loudly. A rejected edit is a better outcome than an approximate one, and most tools here choose the opposite.

The abstraction hides real variation. Backends differ in tool-calling semantics, streaming behaviour and structured output support, and an interface that makes them interchangeable does not make them equivalent. A team that develops against one and deploys against another will discover that at runtime, because no compatibility matrix is published.

What it does right is admitting a limit. Browser automation is explicitly declared out of scope rather than half-shipped, which is a discipline most frameworks of this ambition lack.

The risk is unverified output. terminal_exec is false, so the agent cannot install a dependency, run a build or execute a test; it writes files and shows a preview. A broken import surfaces when you run the project, not when the agent does; the preview only exercises the paths you click.

The consequence is that every generation needs a human build step before it counts as done, fine for a prototype, expensive with a test suite. A terminal tool with test execution would change this verdict. What it does right: the MCP write-up states plainly that servers add dependencies and that queries go to those services.

Category-level consent is the wrong granularity for the dangerous category. Reads and todo updates are fine to wave through, and grouping command execution into the same mechanism means the setting that makes the tool pleasant is the setting that removes the last check before something irreversible. Background tasks make it worse: the prompt you would have read is not on screen.

What it does right is separate the categories at all. Most tools here offer one switch, and a user who wants reads automatic and writes reviewed can have exactly that.

The direction of travel is the problem. Documentation names one agent as the recommendation for new sessions and records the previous harness as deprecated for the largest customers. An organisation that built prompts, evaluations and habits around that earlier path is migrating on somebody else's schedule, and nothing published commits to a second option remaining.

What it does right is separation. Work happens in an environment created for the task, so a failed run damages nothing a developer was holding, and there is no local state to reconcile.

The guard is thin for what it guards. A preset defined in markdown decides which tools a delegated agent may reach, and one of the tools on the other side of that decision executes commands. There is no container, no review step and no documented default beyond whatever the author of the preset typed, which makes safety a configuration exercise done under time pressure.

What it does right is make delegation explicit. A named preset with a declared tool list is inspectable before it runs, which is more than a prompt convention offers.

The exposure grows with the runtime. A mode designed for extended autonomous work, combined with repository write access and no recorded containment, means the window in which something can go wrong is measured in hours rather than in prompts. Nothing published describes a checkpoint, a budget or a stopping rule for a quest that has stopped making progress.

What it does right is externalising state. Rules and memory are declared artefacts a team can read and edit, rather than an opaque profile the product accumulates about you.

The promise moves the failure one layer down. Runs survive restarts because their state is written somewhere, and what that somewhere is remains a deployment decision: an in-memory component during development looks identical in code to a replicated one in production, and the difference only appears the first time a node dies. Coordination inherits the same caveat from the broker.

What it does right is reuse infrastructure rather than invent it. The persistence and messaging are the same ones the surrounding services already use and already monitor.

The risk is that the product is an attacker by design. The README carries its own warning that testing anything you do not own or have written permission for is illegal in most jurisdictions. An agent that misreads a hostname is not a bug report; it is an incident. The claim of working proofs of concept and no false positives arrives without a published false-positive rate to check it against.

The consequence: scope in writing, staging targets only, and a person reading the plan before the run. What it does right is tooling: a real HTTP interception proxy, Caido, rather than a model pretending to be one.

The risk is self-modification. The project advertises that every prompt, tool and configuration file is inspectable and editable, and the agent works with a terminal in the same filesystem. The constraints you write are therefore data the agent can rewrite, and no separate control plane holds them. A long run can drift from its instructions with nothing left to compare against.

Keep the configuration on a read-only mount and diff it between runs. What it does right: the whole thing is packaged to run inside Docker rather than on the host, so the default posture is containment rather than convenience.

Automatic delegation removes the one decision a user is actually qualified to make. When a system decides on its own how to divide a task, a bad division is invisible until the results arrive, and running several sessions at once means the same misjudgement is being paid for in parallel. Nothing published describes how a decomposition is reviewed before it runs.

What it does right is checkpoint. An undo exists for the result, which is the correct pairing for a loop the user did not plan, and it is documented alongside the delegation rather than buried.

The dependency is the risk. Symbol lookup through a language server is more accurate than text search until the index is stale, the project is mid-migration or a Gradle sync has failed, and those are precisely the states an engineer reaches for help in. A tool that is strongest on a healthy repository is weakest on the day it is needed.

What it does right is isolate parallel attempts in worktrees, so two competing approaches cannot write over each other, and abandoning one costs a directory rather than a revert.

The risk is fan-out on a bare host. The tagline promises 100-plus agents in parallel and there is no container layer, so a hundred processes with a hundred shells share one machine and one set of credentials. The parts that would move that work elsewhere are not ready: remote access is marked beta on the pricing page and the mobile app is marked coming soon.

Run a handful, not a hundred, until the remote story is out of beta. What it does right: the scheduled automations are explicit, so unattended runs are something you configured rather than something that happened.

The failure mode is unbounded exploration. In agent mode the model issues shell commands until it decides to stop, and nothing in the documentation states a maximum number of turns. On a large repository one pull request can cost an unpredictable multiple of a plain diff review, and the process that discovers this is your invoice.

The second gap is that it edits nothing: the row records no file editing and no commits, so every comment is work created rather than work removed. What it does right is confining the shell commands to reading, ls, cat, rg and git, which is the correct restriction for a process this open-ended.

The meter is the worst thing. The licensing page prices chat generations, not agent runs, so a user learns the burn rate by running out mid-task. Brave mode executes without confirmation and there is no Docker sandbox behind it, so the unattended path runs on the developer's machine.

The consequence: expect the first month to be a measurement exercise, and keep Brave mode off until you have seen what the plan step proposes. A published credits-per-task figure would change this verdict. What it does right: the CLI runs on your own keys or local Ollama, no meter at all.

The meter is the worst thing. Credits are consumed per prompt and per task, and the pricing page states that Sonnet 4.6 costs 1.3 times the credits of Auto, so the model picker is a price picker with no label. The headless doc documents --trust-all-tools, which auto-approves every tool call, the only approval gate the CLI has.

The consequence is that a CI job with that flag and a bad prompt spends credits and runs commands with nobody watching. Use --trust-tools with an explicit list instead, always. The spec flow is the one thing it does right: requirements, design and tasks before implementation.

The confusion is structural. A plugin, a standalone editor and a command-line agent all carry the brand, and the row's own notes distinguish them: shell execution belongs to the terminal form while the plugin is assistant-shaped. A team comparing notes about what it does is therefore comparing three things, and documentation that treats them as one product makes that worse.

What it does right is Rules management. Team conventions live as a managed artefact rather than as a prompt each developer retypes.

The risk is scope. A framework that answers questions over your database, generates images and transcribes speech has committed to tracking six independent vendor APIs, and a break in any of them lands in the same release train as the agent loop you actually use. Text2SQL against production data is the sharpest edge here: nothing in the description bounds what the generated query touches.

What it does right is the packaging. A BOM artifact means the module versions are reconciled for you, which is the correct answer to a project this wide and more than most JVM libraries ship.

The delegation mechanism is recursion by process. A subagent is the same binary invoked again with a task string, which is elegant and gives the parent no structural limit on depth or breadth. The documentation names the mechanism and names no ceiling, no fan-out cap and no detector for a task that keeps re-delegating itself. That failure is not visible while it is happening; it is visible on the invoice.

What it does right is publish the exact build behind its own numbers, which most vendors on this board decline to do.

The dangerous setting is the one that sounds responsible. Making this a required check means a non-deterministic reviewer holds a veto over shipping, and on the afternoon it flags something wrong the choice is between waiting and overriding a control you just told your auditors was mandatory. Teams resolve this by overriding routinely, which quietly retires the check.

What it does right: it reviews the diff rather than reasoning about the whole repository, which bounds what it can be confidently wrong about and keeps its comments anchored to lines someone actually changed.

The meter is the risk, and it is an unusual one. Pro, Plus and Max are governed by rolling rate limits that are not published on the pricing page, so a limit halts your afternoon rather than charging for it, and you cannot plan around a ceiling you cannot see.

The consequence is that the plan tier is a guess until you have run it for a month, and the failure mode is silence at the worst moment. Publishing the limits would change this verdict. What it does right: bring-your-own-key reaches local Ollama, so a rate-limited team can route around the plan entirely.

The risk is reach. An agent holds the editor, the terminal and a live Chrome window at once, and there is no container sandbox in the capability list, so a wrong shell command lands on the machine you are sitting at and a wrong click lands in a browser session that may be logged in. Three surfaces, one permission model, and the person watching is the only boundary.

Keep the browser profile separate from your own and leave auto-run off for a week. What it does right: New Worktree mode runs the agent in an isolated git worktree, so a bad diff stays off your branch.

The isolated environment is the whole product and the row never says what it is made of. Per-task isolation is claimed, the mechanism is not described, and the difference between a separate checkout and a real process boundary is exactly the difference between two agents that collide and two that do not. Ask before you trust it with anything shared.

Background execution compounds it: a task that goes wrong goes wrong unattended, and you find out when you read the result. What it does right is that the agents it dispatches to are ones you already run, so nothing new is being trusted with your code.

Forgiving parsers fail in the worst way available: quietly and plausibly. A model that emits a slightly wrong call gets its intent reconstructed by heuristics, and the reconstruction is right most of the time, which is exactly what makes the remaining cases hard to notice. A stricter reader would refuse and retry. This one proceeds, and the evidence of a misread arrives as a strange edit rather than an error.

What it does right is patch rather than rewrite. Search-and-replace edits limit the blast radius of a bad turn to the region it named.

The default is where this breaks. Protection relies on a platform-specific backend, and if that backend is missing the run continues anyway rather than stopping, so an engineer who asked for containment gets the appearance of it. There is a second flag that makes it required, and needing a flag to make a safety feature actually safe is a design decision. The worktree and loop features are labelled experimental on top of that.

What it does right: five permission modes with per-tool glob rules, which is a genuinely granular policy surface rather than a single trust switch.

The failure mode is --autoyes. The README marks it experimental and it does exactly what it says: every permission prompt from every agent is answered yes, in parallel, on a real filesystem, because there is no container layer. One agent that decides to reinstall dependencies across a shared cache is four agents doing it. The other documented gotcha is startup timeouts, whose fix is to update the agent underneath.

Leave -y off and read each pane. What it does right: it adds no model layer of its own, so there is nothing of its own to hallucinate, only terminals to manage.

The risk is inheritance. Version 2.0 is described as a ground-up rewrite with no shared code from v1, which is kept on a 1.x branch. The star count, the issue history and the community answers all belong to the old code. What you install today has the maturity of its own commit log, not the project's, and the row on this board has not been verified against it.

The consequence: treat it as a new project that happens to have a famous name, and read the 2.0 issues only. What it does right is SkillScan, a deterministic scanner that checks a skill offline before a model ever sees it.

The default is the failure. Isolation uses operating system primitives, Landlock on Linux and Seatbelt on macOS, and the row states it must be enabled rather than arriving switched on. It also states that network blocking works on Linux and not elsewhere, which means two engineers following the same instructions get two different threat models depending on their laptop. Nothing in the interface announces that difference.

What it does right: choosing kernel and system primitives over a container is honest, because it constrains the process where it actually runs instead of pretending a wrapper is a boundary.

The containment is real and asymmetric. Regular users get an isolated execution environment, which is the correct default and more than most competitors attempt. Administrators get the host filesystem, which means the security property of the whole system is a role assignment in a database. Anyone who can grant that role can leave the box, and prompt injection reaching an administrator session reaches everything they can reach.

What it does right is refuse to reimplement the agent loop. It runs a version-locked vendor runtime directly, so behaviour tracks what that vendor actually tested.

The execution substrate is a laptop. Agent Host pairs a machine and dispatches work to it, which means a run succeeds or fails on whether that machine is awake, online and still authenticated. A platform that keeps working between sessions is being asked to survive somebody closing a lid.

Nothing in the row documents what happens to a dispatched run when the pairing drops mid-task, and there is no sandbox around the shell it is driving. What it gets right is honesty about the boundary: server-run agents and paired-machine agents are separate things, and the docs do not pretend otherwise.

The weakness is the boundary. Protection holds where the managed entrypoints run, and the documentation lists bypassing them as out of scope, so a process avoiding that route is not covered by the controls the page spends its length describing. Encoded or obfuscated secrets are also out of scope, because the scanning is regular expressions and regular expressions do not decode.

Read the scope section before trusting the word sandbox in a meeting. What it does right: the key never enters the box. The agent addresses inference.local while the host holds the credential and upstream endpoint, so a compromised agent walks away with a hostname.

Autopilot is the risk. It watches a pod, and when the pod goes idle it sends the next instruction, which means the only thing standing between a misread ticket and a long expensive afternoon is an iteration cap. Decision history records what happened. It does not judge whether what happened was the right work.

The vendor documents the takeover path, and that is the honest part. A human can seize the pod at any point, which is the correct escape hatch to build first, and more than most tools that run unattended bother to ship.

The row records no git operations. That matters more here than it would elsewhere, because sessions keep working while you are away. An agent that runs unattended for an hour leaves a changed working tree and no commit boundary describing what it did, so the only record of the work is a transcript.

What it gets right is the routing. Backends are interchangeable per project, so a repository that suits one agent is not held hostage to a global setting, and switching does not mean reinstalling anything.