What Is a Local-First AI Agent Workbench?
A local-first AI agent workbench is a desktop application where the durable work stays on a machine you control: files, chats, rules, run history, and artifacts. The user can still choose a cloud model for a task, but the workbench does not require the whole working site to become a cloud workspace.
Agenaxy is one example. It is built for documents, datasets, research, and recurring workflows that need more than a disposable chat answer. You hand off work, choose the model, inspect what happened, and keep the result in formats you can continue editing.
Short definition
A local-first AI agent workbench keeps the working site on your machine and treats models as replaceable labor.
That definition has two parts:
- The working site is local. Files, chats, rules, run history, and artifacts remain on your machine at full fidelity.
- The model is a choice. A task can use a leading cloud model, an open model, or a model running on hardware you control.
Local-first does not mean offline-only. It means the local machine is the durable home of the work, and every remote call has an explicit scope.
Key facts
- The work starts from files and context on a machine you control, not from a vendor-hosted workspace.
- A cloud model receives the context needed for the task you assign to it, not your unrelated chats or the rest of your machine.
- A local model can perform supported tasks without sending model context to a cloud model provider.
- Every run leaves an editable artifact and a structured action record of plans, tool calls, and files touched.
- Agenaxy works on a copy of the files supplied to a chat, so the originals stay untouched.
- Vault Mode locks sensitive work to trusted connections only and blocks unapproved network access at the operating-system level.
- If a Vault step needs an unapproved connection, it stops and explains why.
The five parts of the workbench
1. Local work surface
The work surface is where context accumulates. In a local-first workbench, files, chats, rules, run history, and artifacts live on the local machine rather than inside an Agenaxy cloud account.
This is different from merely opening a local file in a cloud chat. A local file can remain on disk while its contents, conversation, and outputs accumulate in a remote account. Local-first describes the durable home of the whole working site, not just the starting file.
2. Model choice per task
The workbench is not tied to one model provider. You can choose a cloud model when capability matters, an open model when cost or control matters, or a model running on your own hardware when the task should stay within machines you control.
Changing the model should not require moving the files, chats, rules, or run history. The model is hired for the task; it does not own the work.
3. Bounded execution
An agent needs tools to read data, transform files, run commands, or reach external services. Those tools need explicit boundaries. A useful workbench shows what the agent can read, what it can change, and which connections it can make.
Agenaxy preserves the supplied originals and writes working files and artifacts separately. That makes the default handoff non-destructive: whatever the agent does, the source files you started with remain unchanged.
4. Inspectable action record
The final document or table is only part of the result. Agenaxy also keeps a structured action record attached to the run: the plan, tool calls, file reads and writes, and produced artifacts.
This matters when the work needs review. A user can check not only what the agent returned, but also how it arrived there.
5. A stronger boundary for sensitive work
Standard mode supports everyday work with cloud or local models. Vault Mode is the stricter option for work that must remain within a defined set of trusted machines and services.
Vault Mode uses a connection allowlist. A model on the same machine can be trusted; so can a model on a server you control. Web search, external uploads, remote connectors, and other unapproved destinations are blocked. Scripts and commands run under an operating-system sandbox that denies unapproved network access.
Pair Vault Mode with a local model and the task can remain entirely on the machine. If you approve a model on your own server, the context sent for that task reaches that server; Vault does not pretend a remote call is local.
For the complete boundary, see What Is Vault Mode for AI Agents?.
How it differs from adjacent categories
| Category | Durable home of the work | Typical model boundary | Best fit |
|---|---|---|---|
| Chat assistant | Vendor account and chat history | Vendor cloud model | Questions and lightweight drafting |
| Cloud agent workspace | Vendor-hosted workspace | Hosted model and execution | Cloud collaboration and scheduled automation |
| Office-embedded agent | Existing SaaS tenant | The suite's service boundary | Work already centered in that suite |
| IDE agent | Repository and editor state | Cloud or local, depending on setup | Software development inside an editor |
| Desktop file agent | Selected local files plus vendor session | Often a required cloud model | Acting on local files with cloud reasoning |
| Local-first AI agent workbench | Your machine | Cloud or local per task; optional Vault boundary | Durable, file-based work with model choice and auditability |
These shapes are not ranked from good to bad. They optimize for different boundaries. A cloud workspace is useful when shared hosting is the point. A local-first workbench is useful when the work itself should remain with the user.
Standard mode and Vault Mode
| Standard | Vault Mode | |
|---|---|---|
| Intended use | Everyday work | Sensitive work with a strict connection boundary |
| Model choice | Cloud or local | Only models on the trusted allowlist |
| Context sent to a cloud model | The assigned task's context | Only if that model endpoint is explicitly trusted |
| Network tools | Available subject to normal permissions | Unapproved outbound tools and destinations blocked |
| Failure behavior | Uses the model and tools you selected | Stops visibly and explains the blocked connection |
Vault Mode is not simply a new name for “offline.” Its defining property is trusted connections only. A local model is the strictest configuration, but an approved model on infrastructure you control can also fit the Vault boundary.
When this category is a good fit
A local-first AI agent workbench is a strong fit when:
- The work begins with documents, spreadsheets, research, notes, or other files already on your machine.
- You want to use different models without moving the working site between vendors.
- You need editable deliverables rather than answers trapped in a chat thread.
- You want the source files preserved while the agent works on copies.
- You need a record of the steps, tools, and files behind the result.
- Some tasks can use cloud models, while others need a stricter Vault boundary.
It may not be the right fit when the team's source of truth is already a hosted suite, the main job is in-editor coding, or the user only needs quick one-off answers.
What local-first does not promise
Local-first is a system boundary, not a magic privacy label.
- If you choose a cloud model in Standard mode, that provider receives the context sent for the task.
- If you allow a remote model inside Vault Mode, that approved server receives the task context sent to it.
- A local-first workbench cannot control copies you deliberately export to another service.
- Vault Mode does not replace legal, contractual, or organizational review.
The useful promise is narrower and testable: the durable work remains on your machine, remote calls are scoped, and unapproved Vault connections are blocked instead of hidden.
Key takeaways
- Local-first describes where the durable work lives, not only where the model runs.
- Agenaxy keeps files, chats, rules, run history, and artifacts on the local machine.
- Standard mode gives model freedom with task-scoped context.
- Vault Mode restricts work to trusted connections and enforces the network boundary at the operating-system level.
- Every run leaves both an artifact and a structured action record.
- The original files supplied to a chat stay untouched.
FAQ
Is local-first the same as offline-only?
No. Local-first means the local machine is the durable home of the work. Standard mode can call a cloud model for a task. Vault Mode can use a local model or another explicitly trusted model connection.
Is a local-first workbench the same as running a local model?
No. A local model is one possible model backend. The workbench is the larger system around it: files, chats, rules, permissions, tools, artifacts, and the action record.
Does a cloud model see the whole machine?
No. In Agenaxy, a cloud model receives the context for the task you assign to it, not unrelated chats or the rest of your machine.
What is Vault Mode?
Vault Mode is Agenaxy's trusted-connections mode. Unapproved network access is blocked at the operating-system level, only approved model connections can be used, and a blocked step stops and reports why.
Can Vault Mode use a model on my own server?
Yes. Vault Mode is based on an allowlist, not an “offline only” label. A model on this machine or on a server you control can be approved. Context sent to a remote approved server still leaves the local machine and reaches that server.
Are my original files changed?
No. Agenaxy works on a copy of the files supplied to a chat, and writes working files and artifacts separately. The originals remain untouched.
What does a run leave behind?
An editable artifact plus a structured action record covering the plan, tool calls, file reads and writes, and produced files.
Is Agenaxy available now?
Agenaxy is in private beta for macOS. The public website accepts beta requests; it is not the product runtime or a public download page.