Imbue vs Khoj (2026)

Stands at P, and the reasoning is sound though the axis fits awkwardly. Integration here is deep within one class and absent outside it: local git repositories with synced files and git state, the developer's own IDE and dev environment through Pairing Mode, Docker as the execution substrate, devcontainer port forwarding added in a 2026 release, and linters including pylint, ruff and pyre. Section 7's rule is that a deep catalogue inside one ecosystem class is Partial, and this is the developer-toolchain class covered thoroughly. Tool calling in the conventional sense belongs to the agents Sculptor runs rather than to Sculptor: Claude Code and Codex call tools, and Sculptor supplies the container, the repository copy and the verification layer around them. That division is worth stating because it makes the P a description of scope rather than a deficiency; Sculptor is an orchestration and verification harness, not a connector platform. What is absent is any business-system connectivity, no CRM, ticketing, messaging or data warehouse, which is expected and correct for the product. One genuine limit recorded: agent choice is confined to Claude Code and Codex, with the vendor inviting requests for others, so the integration surface for agents themselves is narrower than the container abstraction would allow.

Stands at P. Tool calling is real and the coverage is good for a personal AI: agents are given tools including web search and a code execution sandbox, and documents are ingested from local files and folders, a Notion workspace, and drag-and-drop upload, across PDF, Markdown, org-mode, Word and image formats, with a dedicated Data Sources documentation section. What holds it at Partial is that this is BREADTH, NOT TOOL BREADTH ACROSS CLASSES. There is no connector catalogue: no CRM, ticketing, messaging, warehouse or calendar integrations through which an agent could act on the customer's systems. Khoj reads your documents and searches the web; it does not update your Jira or post to your Slack. WhatsApp, Obsidian and Emacs are client surfaces the user reaches Khoj through, not systems Khoj acts upon, and that distinction is easy to lose when counting integrations. That is coherent for a personal knowledge assistant and the P should be read as describing scope rather than deficiency. Confidence is medium because MCP tool support was asserted in the previous third-party basis and would broaden this considerably if confirmed; the Features section was not opened this pass.

Stands at F. PARALLEL EXECUTION IS THE PRODUCT'S ENTIRE PREMISE: multiple coding agents run simultaneously, each in its own Docker container with a full copy of the repository, so they install dependencies and execute code without colliding. The vendor's argument for why containers rather than git worktrees is the substantive one, that worktrees share the local environment and require reinstalling dependencies for every agent, and it explains why parallelism here is real rather than nominal. That is genuine multi-agent orchestration under this axis, and the coordination surface is complete: a developer spins up agents to explore different approaches, moves between them, merges the work they want, discards the rest, and gets assistance resolving conflicts between parallel branches. Sessions fork from any point, so one agent's state becomes the starting point for another. What is absent, and worth stating so the Full is read correctly, is programmatic composition: no conditional branching, no automated handoff between agents, no workflow definition. A human is the orchestrator throughout, delegating and merging by hand. So this is Full on multi-agent execution rather than on graph orchestration, which is a different shape from n8n or vellum at the same grade. For a comparison page the distinction matters: Sculptor coordinates agents, it does not automate the coordinating.

Stands at P, re-based off the vendor rather than a personal blog. What is documented is agent construction rather than agent teamwork: a customer creates agents with their own knowledge, persona, chat model and tools to take on a role, and the system plans across those tools, runs scheduled automations and offers an autonomous deep-research mode that plans, browses, synthesises and delivers a result. Intermediate steps such as intent detection and web search are themselves model-driven and separately configurable, which is a real multi-step pipeline rather than a single call. What is absent is composition. No multi-agent coordination, no agent delegating to another agent, no branching or conditional graph, and no subworkflow abstraction appears anywhere in the documentation. An agent here is a configured persona with tools, not a node in a system of agents. That is a coherent product position for a personal AI, where the user is the orchestrator and the agent is the worker, and P describes it accurately. Confidence is medium because the Features section was not opened this pass and deep research in particular may be documented as a richer planning loop than the README conveys.

Stands at N, with the basis rebuilt off could-not-be-verified language. Sculptor is a desktop application and every documented route into it is a developer sitting at it: agents are launched on demand, moved between, paired into the local repository and merged by hand. There is no schedule, no cron, no inbound webhook, no event subscription and no channel beyond the application window. That is coherent rather than a gap, and worth stating positively because the grade reads as a weakness otherwise. The product's premise is a developer as architect delegating implementation and then verifying it, and a coding agent that starts itself on a schedule and merges without review is precisely the thing Sculptor exists to prevent. Unattended triggering would cut against the containment and human-approval design that earns Full on oversight and evaluation. The absence also follows from the deployment model: a local desktop app on a developer's laptop has nothing listening for external events, and adding that would require the server architecture the product deliberately avoids. Confidence is high because the product surface is small and fully described; this is not a case where a trigger capability could plausibly be hiding in unread documentation.

P>F. Two of the three classes are strongly covered and the channel breadth is the widest of any vendor reviewed this session. Schedules: the vendor states Khoj automates repetitive research and delivers personal newsletters and smart notifications to the customer's inbox, which is recurring scheduled work with a delivery path rather than a cron field with nowhere to send the result. Channels: browser, desktop, Obsidian, Emacs, phone and WhatsApp are each documented client surfaces, plus email delivery. Reaching a personal AI from inside Emacs and from WhatsApp is an unusual span and it is the product's distinguishing property. That matches the shape that took replit to F this session, schedules plus channels, and it is materially more than the app builders which have channels only. What is absent is the event class: no inbound webhook, no external event subscription, nothing that starts work when something changes in another system. The June basis said wider external event triggers are less documented and that reading holds. Confidence is medium rather than high because the Features section of the documentation was not opened this pass; the automation and notification claims rest on the vendor's README and the client documentation rather than a dedicated automations page. That page would settle whether scheduling is cron-like or richer.

Stands at P. The June basis withheld Full for lacking a documented citation-grounded knowledge retrieval system, which is not the bar; the bar is whether a structure over the customer's knowledge persists between runs. What Sculptor gives each agent is A FULL COPY OF THE REPOSITORY inside its own container. That is genuine grounding in the customer's own material, and it is more complete than the partial context most coding tools assemble, since the agent has the entire codebase rather than retrieved fragments. Devcontainer support means the agent also gets the project's real environment configuration. What holds it at Partial is that no maintained knowledge structure exists over and above the repository itself. There is no index Sculptor builds and keeps current, no ingestion of documents, wikis or specifications, and no knowledge object a developer curates. The repository is the customer's, maintained by the customer through git; Sculptor copies it rather than structuring it. Instruction audit rules are the nearest thing to persistent curated knowledge and they are policy rather than context. That is the same distinction that put bolt at Full for a design system generated from customer material and kept in sync, and holds this at Partial: copying a repo is not maintaining a structure derived from it.

Stands at F and is now based first-party rather than on a hosting provider's deployment template. This is the product's core competence and it clears the persistence line settled today by a distance: knowledge is not assembled per prompt, it is a MAINTAINED SYNCED INDEX. The desktop, Obsidian and Emacs clients keep local files and folders continuously synced to the server, a Notion workspace syncs directly from the web app, and individual files can be dragged in. That index persists in the customer's own Postgres database, so it is a standing object they own outright. Format coverage is unusually wide for a personal-AI tool: PDF, Markdown, org-mode, Word, Notion and images. Retrieval is semantic vector search rather than keyword, and answers carry verifiable citations back to the source document, which is the property that makes grounding checkable rather than merely claimed. One detail worth carrying to comparison pages: because the whole thing self-hosts and can run against local models through Ollama or LMStudio, a customer can index sensitive documents and query them with NO DATA LEAVING THEIR MACHINE AT ALL. Very few vendors in this index can offer grounding and privacy simultaneously; most make you choose.

Stands at P, and the June basis reached the right grade despite naming the wrong reason. It withheld Full for lacking a documented SHARED LONG TERM AGENT MEMORY, which is not the bar; what matters is whether state persists and whether it accumulates. Persistence is genuine and better than most of this lane. Every session is saved with its plans, chats, tool calls and code changes intact, sessions resume across restarts, and they can be FORKED FROM ANY POINT, which is unusual: state is not merely retained but branchable, so a developer can take an agent's context and explore two directions from it. The vendor's framing, that context carries across sessions, is accurate. What is absent is accumulation. Nothing describes an agent learning from a correction, carrying a conclusion from one session into a different one, or updating its own instructions from experience. Instruction audits are rules the developer writes and maintains, not rules the agent revises. That is the line that took gumloop to Full on this axis and holds vellum, make and n8n at Partial. Worth noting the shape is coherent for the product: Sculptor deliberately keeps agents isolated from one another, so shared cross-agent memory would cut against the containment that is the whole design.

Stands at P and the reasoning is the familiar split: real persistence, no accumulation. Persistence is genuine and unusually durable because the customer owns the store: agents carry their own knowledge, the document index lives in the customer's Postgres database and is kept continuously synced by the desktop, Obsidian and Emacs clients, and conversation history persists in that same database rather than in a vendor's session cache. State survives restarts, upgrades and machine changes. What is not documented is memory as something that grows. Nothing describes the agent writing back what it learned, updating its own instructions after a correction, or carrying a conclusion from one conversation into the next. That is the line that took gumloop to F and holds make, n8n and vellum at P. ONE LEAD WORTH RECORDING because it may move this cell. A pull request title in the project's own changelog refers to DISABLING MEMORIES FOR USERS, which implies a memories feature exists as a user-toggleable capability. That is a fragment from a commit log rather than documentation, and I will not grade from it, but the Features section of the docs is the place to check and this is the first thing to look at on a second pass.

P>F, and the June basis withheld Full for falling short of a HARD RUNTIME BLOCKING ENFORCEMENT ENGINE while describing a stronger mechanism than most Full cells in this lane. Section 7 asks for the shipped approval mechanism, and Sculptor's is structural rather than optional: agents work in isolated containers and their changes reach the developer's repository only when the developer brings them across through Pairing Mode and chooses what to merge. Nothing an agent does touches the real codebase without a human act. That is a gate by architecture, not a policy someone can forget to configure. INSTRUCTION AUDITS are the second layer and they are unusual. A developer writes rules in plain English, the vendor's example being never use a particular function, and Sculptor reviews the agent's work against them and reports violations. Plain-English policy that is actually checked, rather than a system prompt hoped to hold, is closer to a guardrail engine than the June basis allowed. Suggestions add a third layer aimed at the deceptive-success case, flagging tests that report passing without testing. The framing worth carrying: this is the one product in the lane whose entire premise is that agent output must be verified before it is trusted. Grading its oversight at Partial understated the thing it exists to do.

Stands at P. What exists are containment and verifiability rather than approval. Agent code runs inside a sandbox, so execution is bounded. Answers carry citations, so a user can check a claim before acting on it. Scope can be constrained so the assistant looks only where the user intends, which reduces fabrication. An admin panel gates configuration behind credentials, and anonymous mode is an explicit, documented choice rather than a silent default. What is absent is a shipped approval mechanism: nothing pauses a run for human sign-off, no checkpoint, no per-tool approval, no queue of pending actions. That is the distinction section 7 draws, and it is what separates this from langflow's Human Input node, mindstudio's Checkpoint block and zapier's Needs-action queue, all of which reach F. Worth noting rather than crediting: the risk profile here is unusually low by construction. A self-hosted personal AI that reads your documents and answers questions has little capacity to take a damaging action on your behalf, because it is not wired into systems it can change. Guardrails matter less when the blast radius is small, and P reflects the mechanism rather than a judgement about whether more is needed.

N>P. The June basis used could-not-be-verified language and graded absence, but real customer-facing security controls are documented and they are the right ones for what this product is. CONTAINER ISOLATION PER AGENT is a security control, not just an engineering convenience. The vendor's framing is explicit: containers let each agent install packages and run code without risking your machine, and the contrast drawn with git worktrees is precisely that worktrees share the local environment. An agent executing arbitrary generated code is a genuine threat to a developer's machine, and isolating it is the mitigation. LEVELS are the governance control, with the customer choosing what returns to Imbue and the Essential-only setting described by the vendor as the safe choice for work code. Code is not used for training by default, and everything runs locally, so there is no vendor-side store to govern. What is absent is the attestation half of the section 7 conjunction and any identity governance: no certification, no single sign-on, no role-based access, no audit of who did what across a team. This is a single-developer tool in beta, so that is expected rather than a failing, and it is why the cell sits at Partial rather than higher. The same shape holds khoj at Partial, where local execution and admin controls exist without certification.

Stands at P, and P is the correct shape for a self-hosted AGPL project rather than a criticism of one. Real controls are documented: an admin panel with credentialed access, an admin account created on first run, a separate authentication setup path, an explicit anonymous mode for single-user local installs, and configuration of allowed domains and HTTPS behaviour for exposed deployments. A privacy page documents the data position. What cannot be present is the attestation half of the section 7 conjunction. There is no certification that could cover a customer's own self-hosted instance, because the customer runs the infrastructure; that is a property of the delivery model, and it is exactly why langflow and n8n sit here too rather than being marked down. One thing worth carrying to a buyer: because the cloud service is gone, THE PERIMETER IS ENTIRELY THE CUSTOMER'S NOW. There is no vendor-side environment left to assess, which simplifies a security review to reviewing your own deployment. The documentation is candid about the sharp edges of that, warning that Khoj is only reachable on its own machine by default and that exposing it requires deliberate configuration.

P>F, and the June basis contradicted itself. It recorded that every session is saved with its plans, chats, TOOL CALLS and code changes intact, then withheld Full for falling short of a documented production monitoring and audit system. Production monitoring is not this axis. A complete record of what an agent planned, what it said, which tools it called and what it changed is precisely the per-action trace that separates auditing from reporting, and most records in this lane sit at Partial for lacking exactly this. Two features make it stronger still. SUGGESTIONS flags misleading agent behaviour, with the vendor's own example being tests that report passing without really testing anything, so the system surfaces the specific failure mode a trace exists to catch. And Pairing Mode syncs an agent's work into the local repository and git state, so an agent's output is inspectable in the developer's own editor and diff tools rather than only through the vendor's interface. Sessions can be resumed and forked from any point, which turns the trace into something navigable rather than a log to scroll. The honest limit, recorded rather than used to withhold: there is no aggregate view across sessions, no analytics and no fleet-level reporting. This is deep observability of one developer's agents, not an organisational dashboard, which suits what the product is.

Stands at P, re-based off the vendor rather than a directory listing. The genuine item is CITATIONS: answers carry verifiable references back to the source documents, which lets a user check why an answer was given rather than only what it said. For a retrieval product that is the most load-bearing form of transparency there is, and it is more than several vendors graded at P elsewhere offer. An admin panel provides configuration review and, being a Django admin over the customer's own database, exposes the underlying records directly. Server logs are configurable and the customer holds the database outright, so anything not surfaced in the interface is still reachable by query. That is a real fallback that only self-hosted products can offer. What is absent is agent-level observability: no execution trace, no record of which tools an agent called with what arguments, no run history view, no audit log of user actions, and no analytics. A user sees the answer and its citations, not the path taken to produce them. Confidence is medium because the Features and Advanced Self Hosting sections were not opened and a telemetry or logging page could sit in either.

P>F. The June basis withheld Full for falling short of a documented enterprise on-premises or dedicated residency offering, which inverts what this axis measures. SCULPTOR RUNS FULLY LOCALLY ON THE DEVELOPER'S OWN MACHINE. That is not short of on-premises; it is the most complete form of it, because there is no vendor environment for code to reach in the first place. The data position is documented with unusual precision. The vendor states Sculptor runs fully locally and the customer controls what data it sends back, with named levels, and describes the Essential-only setting as sharing just error logs and basic usage, calling it the safe choice for work code. A vendor that labels its own most restrictive setting as the right one for employer code is being straight with developers rather than maximising telemetry. Execution is containerised per agent, each with a full copy of the repository, so the isolation is between agents as well as between agents and the host machine. Distribution covers macOS and Linux natively with Windows through WSL. The comparison worth carrying: khoj reaches Full on this axis by being self-hostable, and Sculptor goes further by never requiring a server at all. For a developer whose employer forbids source code leaving managed devices, that is the whole decision.

Stands at F, and the grade is now stronger than when it was written because SELF-HOSTING IS NO LONGER ONE OPTION, IT IS THE ONLY ONE. Khoj Cloud was sunset on 15 April 2026 and the vendor directs customers to self-host for complete data ownership. A record that used to describe a choice now describes the whole product. Installation is documented for Docker, Docker Compose and pip across macOS, Windows via WSL2 and Linux, with the customer's own Postgres database, an embedded database option, and configuration through environment variables including domain, HTTPS and reverse-proxy settings. Remote access has its own page, and auto-start via cron or Task Scheduler is documented. Upgrade and uninstall paths are both written down, which is a small thing that indicates the self-hosting story is maintained rather than aspirational. The residency answer is absolute: the vendor states data never has to leave the customer's private network, and Khoj can run WITHOUT AN INTERNET CONNECTION AT ALL when deployed on a personal computer with local models. That is the strongest form of this axis available, matching n8n and langflow, and it is the reason the record survives the cloud sunset with its value intact.

Stands at N, but the June basis contained a self-contradiction that needs recording rather than repeating. It stated that Sculptor OFFERS A FEW PREBUILT CODING WORKFLOWS AND REPOSITORY TEMPLATES and then graded N because a browsable library or marketplace could not be verified. Under the 31 August wider bar a catalogue is evidence of the bar rather than its definition, so if those templates exist the grade should be Partial at least; and if they do not, the basis should not have asserted them. I could not corroborate them this pass. The vendor's product page, announcement and public repository describe the application, its containers, Pairing Mode, instruction audits and suggestions, with no template library, starter workflow set or shareable configuration surface. So N stands on what I could verify, and the previous assertion is not carried forward into the basis. The grade is also coherent with the product. Sculptor supplies the harness; what the customer brings is their own repository and the coding agent they already pay for. There is nothing to package, because the reusable asset in this workflow is the developer's instruction audit rules, and those are written per project rather than distributed. Confidence is medium: a templates or examples directory could exist in the public repository, which I did not enumerate.

Stands at N under the 31 August wider bar, which asks whether the customer receives packaged assets ready to adopt by any route, not whether a browsable catalogue exists. Khoj provides the machinery to build an agent, with custom knowledge, persona, chat model and tools, and the vendor points to a blog post giving a step-by-step guide to creating one. But a guide teaches you to build; it does not hand you something built. No template library, no preset agent set, no shareable agent format, no community gallery and no starter pack appears in the documentation navigation. That matters more now than it did in June. With Khoj Cloud sunset, a new user starts from an empty self-hosted install, so whatever preset agents may once have existed on the hosted service are no longer a route to anything. The absence is therefore more complete than the record's June assessment implied rather than less. Confidence is medium because the Features section was not opened this pass and an agents page could plausibly list presets. If it does, this moves to Partial or Full depending on whether they are vendor-supplied and adoptable.

P>F. The June basis withheld Full for falling short of A DOCUMENTED ROUTING GATEWAY, which is not this axis. The question is whether the customer chooses the model powering the product, and here the customer chooses more completely than almost anywhere else in the index: Sculptor supports Claude Code and Codex, the customer supplies their own key or their own Claude Pro or Max subscription, and a 2026 release added support for ANY ANTHROPIC-COMPATIBLE API KEY, which opens the door to proxies and self-hosted endpoints. The bring-your-own-key arrangement is not a convenience here, it is the commercial model. Sculptor is free in beta precisely because the customer pays the model provider directly, so Imbue never sits between the developer and the model. That means there is no vendor markup, no opaque routing and no possibility of silent model substitution, which is the failure mode this axis exists to detect. Model availability tracks releases quickly, with Opus 4.5 support arriving in a 2026 release, and the vendor invites requests for additional agents through its Discord and public channels. Worth carrying to a comparison page: this is the fullest form of the axis, customer chooses the agent, the model and the billing relationship, and it is a direct consequence of Sculptor being an orchestration layer rather than a model vendor.

Stands at F, now first-party, and it is one of the strongest Model cells in the index because choice reaches all the way down to running no vendor's model at all. Commercial providers are configured by API key for OpenAI, Anthropic and Gemini; local and offline models run through any OpenAI-compatible server including Ollama, vLLM, LMStudio and llama-cpp-server, with the base URL pointed wherever the customer wants. The configuration model is genuinely granular rather than a single dropdown. An AI Model Api object holds the provider credential, chat models are registered individually against it with tokenizer and max-prompt-size fields, vision capability is a per-model flag, and a user picks their preferred model in their own settings. Above that, ServerChatSettings carries separate DEFAULT AND ADVANCED model choices which Khoj uses for intermediate steps such as intent detection and web search, so a customer can run a cheap model for routing and an expensive one for the answer. That split is a real cost lever and almost nothing else in this lane exposes it. Combined with self-hosting, this is the complete form of the axis: the customer chooses the model, the provider, and whether inference happens on their own hardware.

Stands at P, with the basis rebuilt because the June one withheld Full on the grounds that an API, SDK or MCP support is ON THE ROADMAP RATHER THAN SHIPPED. That reasoning was correct and is preserved: section 7 is explicit that roadmap is not shipped, and it is the one place in this cohort where a build applied a real rule rather than an invented one. What is shipped and does support Partial: Sculptor is OPEN SOURCE with a public repository, and custom checks can be defined using shell commands and plain-English rules, so a developer extends the verification layer without waiting on the vendor. Devcontainer support means a project's own configuration governs the agent's environment. A deliberate contrast with khoj, graded Full on this axis earlier today largely on its open licence. Khoj is a server that its own desktop, mobile and editor clients reach over HTTP, so something outside it can call it. Sculptor is a local desktop application with no callable surface: open source lets you modify it, not invoke it. Mike's 30 August bar asks whether the platform is callable from outside through a documented API or SDK, and forking a codebase is not that. That comparison also flags a possible over-grade on khoj, whose own basis notes no API reference exists in its documentation navigation. Worth re-examining when khoj next comes up.

Stands at F but the basis is rebuilt, because the June version rested on a third-party directory listing rather than the vendor. What carries the grade now is the licence: Khoj is AGPL-3.0 with the full server, all clients and the documentation in one public repository at 36,700 stars and 2,400 forks, still receiving commits in August 2026. A customer can read, modify, fork and run the entire product, which is the strongest extensibility guarantee available and the same reasoning that supports langflow and n8n. Beyond the licence, the client surface implies and depends on a server API: the desktop, Obsidian, Emacs and WhatsApp clients all talk to a self-hosted server over HTTP at a configurable host URL, and the documentation instructs users to point each client at it. Agents are documented as taking custom tools. CONFIDENCE MEDIUM AND THE GAP NAMED PRECISELY: the documentation navigation covers Get Started, Contributing, Features, Clients, Data Sources, Advanced Self Hosting and Miscellaneous, with NO API REFERENCE SECTION. So a REST and websocket API and MCP tool support, both asserted in the June basis from a third-party directory, were not confirmed first-party this pass. Reading the Features and Advanced Self Hosting sections would settle it; if no documented API exists, this cell rests on the open licence alone and should be re-examined.

Stands at F and is the cleanest Eval cell in the index, because verification is not a feature here but the company's research thesis: Imbue's stated mission is improving the ability to verify the correctness of code generated by language models. Under the 31 August bar, Full requires a result the customer can read and compare. Sculptor produces three. TESTS RUN IN THE CONTAINER and their results are reported, so correctness is established by execution rather than assertion. INSTRUCTION AUDITS check the agent's work against rules the developer wrote in plain English and report violations, which is a judge verdict against a customer-defined standard, the exact shape the bar names. And SUGGESTIONS flag misleading behaviour, with the vendor's own example being tests that report passing without really testing, which is evaluation of the evaluation and rarer still. Linters including pylint, ruff and pyre are integrated, so static checks sit alongside dynamic ones. Pairing Mode then lets the developer run the agent's work in their own environment, which is the customer testing against their own workload rather than the vendor's. The contrast that makes the grade clear: replit and lovable sit at Partial because an agent checking its own build produces no readable comparable result. Sculptor's audits and suggestions produce exactly that, and they are adversarial towards the agent rather than performed by it.

Stands at N under the 31 August Eval bar, and confidence rises to high because the documentation navigation is fully enumerated and contains nothing on this axis. The bar has three positions: Full needs a result the customer can read and compare, Partial is a quality gate with no readable result, None is neither. Khoj has neither. No test suite, no metrics, no scoring, no regression comparison, and equally no self-check gate of the kind that puts replit and lovable at Partial. An agent's output is produced and returned; nothing inspects it before it reaches the user. Citations are deliberately not counted here. They let a HUMAN verify an answer after reading it, which is transparency and is credited on Obs; they are not the system testing anything. Reading a citation is the user doing the evaluation, which is precisely what this axis asks the product to do. This is a coherent gap rather than an oversight, and worth stating plainly on comparison pages: Khoj is a retrieval and personal-AI product, and evaluation infrastructure is what a team building agents for others needs, not what one person querying their own notes needs. Vellum sits at Full on this axis for exactly the opposite reason.

Stands at N, and confidence rises to high because the June basis used could-not-be-verified language while the answer is settled by the product's own architecture. Sculptor's agents execute code and run terminals inside Docker containers. CODE EXECUTION IS NOT COMPUTER USE, which is the single most repeated error on this axis, corrected thirteen times in the Coding agent June cohort and refused again this session on khoj's Python sandbox, stackai's terminal and bolt's WebContainer runtime. A container running a test suite is running a program, not operating an interface that lacks one. Devcontainer port forwarding, added in a 2026 release, lets a developer open the application an agent is building in their own browser. That is a human viewing output, and it is the same refusal applied to lovable's browser testing and bolt's live preview: rendering your own product is not driving someone else's. Everything else the agent touches, the filesystem, git, package managers, linters, is reached programmatically by design, because the container exists precisely to bound what the agent can affect. The absence is structural: a tool built to contain agents inside isolated environments has no path to, and no interest in, letting them drive arbitrary software on the host.

P>N, and the June basis argued itself into the wrong grade. It read: a code execution sandbox lets agents run Python safely, A REAL FORM OF COMPUTER USE, though interactive control of a browser is not documented and web access is retrieval only. The subordinate clause describes N precisely; the main clause then graded P on the sandbox. CODE EXECUTION IS NOT COMPUTER USE. That is the single most repeated error on this axis, corrected thirteen times in the Coding agent June cohort, and refused again this session on stackai's terminal sandbox and bolt's WebContainer runtime. The axis is non-zero only when an agent operates software that has no programmatic interface. Khoj's sandbox runs Python the agent wrote, which is executing code, and its web access is retrieval, which section 7 is explicit is not computer use. Nothing in the documentation describes navigating, clicking or driving any interface. WORTH KNOWING FOR THE INDEX RATHER THAN FOR THIS CELL: the same company's newer product, Pipali, explicitly does use a browser. That capability exists at Khoj AI but it is not in Khoj, and putting it here would credit this record for a different product. Pipali is flagged on the vendor record as a build candidate.