Level 01
Supervised
Every read, edit and command prompts first.
- Reads
- Asks first
- Edits
- Asks first
- Commands
- Asks first
Agent runtime · VS Code extension + CLI
Your policy, enforced. Nx IDE.
A VS Code extension and CLI whose agents plan, edit, run and test code on the developer's machine. Orchestrator mode adds an isolated Tester and Reviewer to each change. Models come from 20+ providers or a local runtime; editor actions prompt by default, while the CLI approves commands unless told otherwise.
31 modes, 10 of them core 20+ providers or local runtimes Telemetry: none
Distributed as the Nxgyle Code .vsix extension. Model calls stay blocked until a Nxgyle license key passes an offline signature check.
Platform context
Nx·Studio generates digital workers and exports each as a complete codebase. Nx IDE runs policy-bound coding agents for the systems around them. The Cognitive Engine answers routine decisions only after passing an exam on held-out cases.
Architecture of the three products Architecture
An agent runtime inside VS Code.
One extension, one CLI, one policy model. Agents read the repository, draft a plan, edit files and execute commands and tests locally. Editor sessions hold every edit and command for approval unless a rule releases it.
Cross-checking
Separation of duties, in code.
Orchestrator mode splits each change across roles. Code agents implement it, a Tester and a Reviewer verify it in parallel without the implementer's reasoning, and by default shipping waits for an explicit human yes.
Best fit
Repositories under change control.
Engineering organizations with audit, security or modernization obligations. Policy lives in versioned files beside the code (permissions, hooks, ignore lists), and the model provider stays your choice.
Task lifecycle
Five stages from prompt to diff.
Every task passes the same five stages, and your permission policy decides which of them prompt a person.
01
01
Task intake
The developer writes the requirement as ordinary prose. Every session begins in Code mode, and a slash command moves to any of the 31 modes. An @ mention attaches files, compiler errors, terminal output, PDFs, office documents or spreadsheets as context.
02
02
Plan review
Non-trivial changes open in Plan mode, which can edit only plan documents. Reviewers annotate individual passages and only those passages are regenerated. Implementation starts after approval, which at higher dial levels can come from a countdown.
03
03
Permission policy
Editor defaults require approval for every edit and command. The five-level Delegation Dial and allow, ask and deny rules release specific actions. Commits, pushes and deployments are instructed pauses until a deny rule makes them hard blocks, and the CLI approves commands by default.
04
04
Checkpoint trail
Each agent change lands in a shadow version-control repository, so any two states can be diffed and any earlier one restored in a click. Terminal side effects are not undone. A live meter tracks task spend and context-window use.
05
05
Exit verification
When a task has modified files, a default self-review rereads the diff, runs the project's build and tests, and returns a per-change summary before the task closes.
model layer
Bring your own model endpoints.
Over 20 model providers are supported, including local models and compatible gateways. Changing provider is a configuration step, not a migration, so each team keeps the vendor its security review already cleared.
Local inference
Self-hosted model servers keep prompts and source on your own hardware, inside your network.
Existing contracts
Point it at model accounts you already contract for, or at the models your editor already exposes.
Per-mode model binding
Bind separate models to planning, coding and review; each mode keeps its own selection, so premium models run only where accuracy matters.
OS keychain storage
Provider keys sit in the editor's secret storage, which is backed by the operating system credential store rather than settings files.
egress
No Nxgyle proxy in the path.
Requests go from the workstation to the provider endpoint you configured, and Nxgyle operates no proxy. The telemetry client is a no-op stub, and the license key is checked offline against its signature.
No telemetry calls
The usage-reporting client is compiled as a no-op, so no code, prompt or activity data is sent to Nxgyle.
Provider-direct traffic
Every call targets the endpoint in your configuration; with a local model, model traffic never leaves the machine.
TAA edition
Where Trade Agreements Act (TAA) rules apply, a separate build removes every restricted-origin provider and model family, with no user override.
Excluded paths
Anything on the ignore list is hidden from every agent and every mode.
code graph
Impact analysis before review.
Cortex builds a local code graph with no network requests and no API key. It maps subsystems, execution flows, import cycles and service boundaries, and grades each proposed change from LOW to CRITICAL.
Graded impact
Dependency rules, a taint scan inside single functions, and graph export to five standard graph and diagram formats.
Older code, translated
Translate mode produces one target file per source file and marks every change, so modernization plans start from reviewable output.
Session memory
Per-project notes survive restarts, and a search over prior conversations recovers earlier decisions.
Document ingestion
PDFs, office documents, spreadsheets and web pages attach as context; opt-in research can also read other repositories.
enforcement
Guards enforced outside the model.
Approval prompts are one layer. Six guards hold whatever the rules say: .env reads, hidden shell substitutions, protected files, self-edits to permission or hook files, always-ask tools and catastrophic deletes.
Shadow checkpoints
On by default and stored in a shadow version-control repository, so any earlier task state restores in one click. Version control must be installed, and terminal side effects remain.
Path scoping
Edit permissions can be limited to chosen paths, and automation-launched tasks can be pinned to named folders by the tool layer itself, not by prompt instructions.
OS sandbox, opt-in
The operating system's own sandbox on macOS and Linux confines writes to the workspace, strips credential variables and can cut the network. There is no Windows support, and reads stay unrestricted.
Whole-file writes
Truncated writes, and edits that swap code for placeholders such as “rest of the file unchanged”, are rejected before they reach disk.
extensibility
Modes, agents and skills as files.
Thirty-one built-in modes (10 core, 21 specialists) ship with the extension. Custom modes and agents are plain text files at project or global scope, reload live, and go through review like any other code.
31 modes, scoped tools
Each mode carries its own tool limits: Plan edits only plan documents, Chat can neither edit nor run commands, and Tester cannot edit.
Agents as code
Custom agents live as text files in the project's agent folder, versioned and reviewed through your normal pull-request flow.
Tool servers and skills
Global or per-project tool servers and a skills marketplace; a project's servers start only after the workspace approves that exact file.
Rules files
Rule files (per mode where needed), a shared instruction file and a protected-file list encode your engineering conventions for every mode.
multi-agent chain
Implementers and verifiers, isolated.
Orchestrator mode gives the change to one implementer or a team of two to five. Tester and Reviewer then run side by side, and at the default setting “Ship?” goes to a person before the Shipper commits anything.
01 Code agents, 1 to 5
Implement
Single coder or a 2–5 agent team
02 Tester · Reviewer
Test + Review
Parallel, no shared reasoning
03 You
Ship?
A person must say yes
04 Shipper
Ship
Feature branch; no push to main
Context isolation
Tester and Reviewer get only the requirement and the file list, not the implementer's chain of reasoning, and neither holds write tools.
Bounded rework
Failed tests or review findings allow at most two retries, three rounds in all, before a person decides; a critical finding goes to a person at once.
Chain-wide stop
Stop aborts every role in the chain together, and the agent map shows which role currently holds the task.
Scale-out
Agent Manager
One panel for concurrent sessions, showing progress, spend and pending approvals for each agent.
Scale-out
Agent Teams
Two to five Code agents split a change that divides cleanly, for instance API and UI work, coordinating through a shared task list and messages you can inspect.
Scale-out
/batch
A read-only planner proposes up to 30 tasks under one approval. Each runs in its own isolated workspace and branch, two at a time by default, with an optional draft PR.
Scale-out
/review
As many as five reviewers read the diff in parallel without write access; fixes begin once you pick which findings matter.
Per its instructions, the Shipper commits to a feature branch only: no push to main, master or develop, and no force-push. “Ship?” requires approval: on the two lowest dial levels it waits for a human reply, and above those levels a deny rule enforces the same.
Policy enforcement
Controls in the tool layer.
Approvals, permission rules, lifecycle hooks and role separation, implemented in the extension itself rather than in a separate gateway.
01
Approval default
The editor's auto-approve switch and every always-allow flag ship disabled.
02
Rule engine
Allow, ask and deny rules per action type (shell, edit, read, tool call), and each auto-approval names the rule that matched.
03
Release gates
Agents are instructed to stop before a commit, push, deploy, migration or delete; adding a deny rule hardens that stop into a block at any dial level.
04
Blocking hooks
Scripts on eight lifecycle events, TaskStart through TaskAbort, can veto progress; project hooks run only after workspace approval.
05
Tamper resistance
No agent may modify its own permission or hook configuration, and a project rule file can only tighten user-level rules.
06
Read-only checkers
Tester and Reviewer modes are built without file-writing tools.
Permissions, rules, hooks and the sandbox run in the extension's tool layer, outside the model, so none depends on the AI choosing to comply.
Security posture
Answers live in configuration.
Security reviews of AI coding tools come down to three questions: who authorized an action, what it cost and what the agents could touch. Each answer traces to configuration or usage data.
Q1
Who authorized this action?
A person at the prompt, or a rule a person wrote, and each automatic approval cites its matching rule. Editor sessions prompt by default, CLI runs need --require-approval to prompt, and deny rules bind sub-agents too.
Q2
How is spend metered?
A live USD meter per task, plus a Usage & Cost dashboard by day, model, project, mode and source with spreadsheet export. Budgets only alert; optional cost and request caps pause a task.
Q3
What is in the agents' reach?
Whatever the permission rules, the ignore file and the optional sandbox allow. Six guards hold regardless of rules and the checker roles have no write tools; the sandbox restricts neither reads nor per-destination egress.
Controls are per-repository and per-machine files. Review them, version them beside the code and map them to the controls your organization already runs.
Read the Trust Center autonomy levels
Five autonomy levels, one dial.
The Delegation Dial under the chat box moves the agents from Supervised to Autonomous in five steps, and each step widens what runs without a prompt.
Note for reviewers: checkpoints stay on at every level. Above Supervised, sub-agents launched by another agent, such as the Orchestrator's roles, inherit every auto-approval, though written deny rules still bind them.
Every prompt Fewest prompts
Level 02
Trust reads
In-project file reads run unprompted; edits and commands keep prompting.
- Reads
- Unattended
- Edits
- Asks first
- Commands
- Asks first
Level 03
Trust edits
Reads and edits run unprompted. Routine questions, plan approval included, default to their top suggestion if 60 seconds pass with no reply. Commands still prompt.
- Reads
- Unattended
- Edits
- Unattended
- Commands
- Asks first
Level 04
Trust execution
Reads, edits, commands and tools marked always-allowed run unprompted. Spawning sub-agents, protected or out-of-project files and always-ask tools still prompt; deny rules keep blocking.
- Reads
- Unattended
- Edits
- Unattended
- Commands
- Unattended
Level 05
Autonomous
Everything runs unprompted except in three cases: deny rules still block, protected or out-of-project edits still prompt, and so do a few always-ask actions such as web fetches.
- Reads
- Unattended
- Edits
- Unattended
- Commands
- Unattended
Mode catalog
Ten core modes with scoped tools.
Each mode ships with its own tool permissions, and the Orchestrator composes several into a chain for one task.
Plan
Writes the plan; edits plan files only.
Code
Full edit and command tools for implementation.
Chat
Answers questions; no edits, no commands.
Debug
Reproduces a defect, isolates the cause, patches it.
Orchestrator
Runs the implement, test, review and ship chain.
Tester
Executes tests and holds no write tools.
Reviewer
Reviews the diff in a fresh, read-only context.
Shipper
Commits approved work to a feature branch.
Spec Bootstrap
Generates a project wiki and rule files.
Spec Sync
Keeps that wiki in step with new commits.
Plus 21 specialist modes for scoped jobs
RefactorTest GenDoc GenSecurityAPI ModDep UpgradeIssue FixerPR FixerMerge ResolverDocs ExtractorIssue InvestigatorIssue WriterDB MigratorDB ArchitectCode ArchitectDevOpsAPI TesterCode ReviewerTranslateUI DesignerDev
Need another? Define a custom mode in a plain text file at project or global scope, and it reloads live.
Capability map
Engineering work it can carry.
Nine areas of engineering work, each bounded by the same permissions, dial level and checkpoints.
Plan stage
Agree the design before implementation.
- Plan documents with passage-level annotation
- Code Architect and DB Architect specialists
- Spec Bootstrap and Spec Sync wikis
Build & renew
New features and legacy renewal.
- Feature work, fixes and refactors
- API Mod, Dep Upgrade and DB Migrator modes
- Legacy work, via Translate mode
Testing
Catch regressions before merge.
- Test Gen and API Tester specialists
- Build-and-test self-review at task close
- An independent Tester in Orchestrator runs
Review & commit
Independent review, then a gated commit.
- /review: five parallel, no-write reviewers
- Editor approvals on by default
- Shipper commits to a feature branch only
Code intelligence
Repository-wide context, computed locally.
- Cortex graph: flows, cycles, LOW-to-CRITICAL risk
- Session memory and conversation search
- Semantic code search after indexing
Integration
Connects to your existing toolchain.
- Tool servers, global or per project
- Skills and tool-server marketplace installs
- Optional browser check of the built app
Controls
Enforced in the tool layer.
- Prompts by default; five-level Delegation Dial
- Allow, ask and deny rules; eight hook events
- Opt-in macOS and Linux sandbox
- Per-task cost meter; alert-only budgets
Scale
Concurrent agents per engineer.
- Agent Manager across sessions
- Agent Teams of two to five Code agents
- /batch: up to 30 tasks, one workspace each
Ergonomics
Quality-of-life features for daily work.
- Checkpoint diffs and one-click restore
- Opt-in inline completion and dictation
- Natural language → drafted shell commands
- Editor sidebar or standalone browser tab
Recent changes
Recent additions, by area.
- Parallel
Isolated batches and agent teams
Concurrent sessions in Agent Manager, coordinated Code-agent teams, and /batch runs that fan one change out across isolated workspaces with optional draft PRs.
- Review
Passage-level plan review
Reviewers comment on single plan passages before implementation, and /review fans the diff out to five read-only reviewers.
- Rules
Rule engine, hook events, sandbox
Per-action allow, ask and deny rules, eight vetoing hook events and the opt-in operating-system sandbox for macOS and Linux.
- Recall
Memory, research and cost data
Cross-session notes, document and web research, and a Usage & Cost dashboard with spreadsheet export and alert-only budgets.
- Catalog
Current frontier models
Newly released models from the major labs appear in the picker.
Opt-ins
Off at install, on by choice.
Ships off
- OS sandbox (macOS and Linux; no Windows support)
- Per-task cost and request caps
- Web search and cross-repo research
- Built-app browser check (needs Chrome or Edge)
- Automatic project-memory notes
- Completion, read-aloud and dictation (dictation needs FFmpeg and a transcription key)
One-time setup
- Semantic code index
- Tool servers: configure your own or install from the marketplace
Straight answers
What engineering leaders verify.
Answers you can check in config.
Raise another questionWhen does it act without a prompt?
When a rule or the dial allows it.
Editor sessions prompt by default, and the CLI approves commands unless run with --require-approval. Above Supervised, sub-agents inherit auto-approvals, but deny rules and the six built-in guards still apply.
How is model spend bounded?
Every task shows live USD cost.
Optional per-task cost and request caps pause a task at the limit and stop it if declined; daily and monthly budgets only alert.
Can we switch model providers?
Yes.
Support spans 20+ model providers, local models and compatible gateways included; the separate TAA build drops restricted-origin providers entirely.
Does any code reach Nxgyle?
No.
The telemetry client is a no-op, the license check runs offline, and requests go only to the endpoint you configure.