Level 01
Supervised
The lead allows nothing unattended: every action waits for approval. New teams start here.
- Reads
- Approval
- Edits
- Approval
- Commands
- Approval
For delivery teams · AI roles in VS Code
Equip your team with Nx IDE.
Engineers brief the work, AI roles plan, write and check it, and reviewers approve each step. In Orchestrator mode, separate roles test and review every change, and, unless the autonomy dial is raised, shipping needs a person's yes. Team leads choose the model vendor or a local model, set the action boundaries and, if they wish, a spend cap per task.
31 built-in modes Over 20 vendors, or local Usage stays private
Rollout needs a valid Nxgyle license key, verified offline; Nx IDE installs in VS Code as the Nxgyle Code extension.
Platform roles
Nx·Studio is where process owners shape the digital workers their teams run. Nx IDE is where engineering teams build and maintain the software around them. The Cognitive Engine takes routine decisions only once a rule qualifies.
See which team uses which product What your engineers get
AI roles inside the editor they use.
An engineer briefs the task in plain language. Nx IDE reads the codebase, proposes a plan, edits the files and runs the tests, holding each change for that engineer's approval by default.
What changes for reviewers
Checking no longer rests on one person.
With many coding assistants, the developer checks everything alone. In Orchestrator mode one role writes, separate test and review roles verify, and the chain puts the shipping question to a person.
Which teams it suits
Teams that already run change control.
Delivery teams in regulated sectors, including those maintaining or modernizing older platforms. Approval checkpoints, written rules and a model per role fit the change process your managers already run.
Daily task flow
Who acts at each step of a task.
At each step your engineers can inspect, approve or restore the work. How much runs unattended is set by you.
01
01
Brief the task
The engineer states the need in plain language. Each new chat opens on Code mode; a slash command (/) moves it to any other built-in mode, 31 in total. Typing @ attaches files, errors, terminal output, PDFs, or Word and Excel content.
02
02
Annotate the plan
Larger changes start in Plan mode with a written plan. Reviewers comment on any section, and only that section is revised. Building waits for plan approval, given by a reviewer or, at higher dial levels, after a countdown.
03
03
Set what runs unattended
By default, editor sessions hold every change and command for a person. Team leads loosen it per project through written rules and the Delegation Dial's five levels. Agent instructions call for a stop before any commit, push or deployment, and deny rules make that stop binding at any level.
04
04
Track work and spend
While the agent works, checkpoints save file snapshots anyone on the task can compare or restore with a click. A running meter tracks estimated spend and how much context the model has used so far.
05
05
Close out with checks
When a task changed files, it closes by default with a self-review, a full build and test pass, and a summary of the changes for your reviewer.
vendor policy
Assign cleared models to each role.
Team leads pick from vendors your security colleagues have already cleared: over 20 providers, from major AI clouds to open-model hosts, or models on your own hardware. Changing vendor is a settings change, not a project.
Local hosting for sensitive repos
Where policy keeps code in-house, leads point roles at Ollama, LM Studio or another compatible server on your own machines.
Use contracts you already hold
Teams can connect an existing chat-assistant subscription, or the models VS Code already offers, before anyone buys new seats.
A model chosen per role
A lead can store a model per role, so planning runs on one model while coding and review use others.
Keychain-held keys
Vendor API keys live in the operating system's keychain or credential manager, never in a shared settings file.
where data goes
Nxgyle sees no code or prompts.
Each request leaves the engineer's machine for the model vendor your team chose; nothing passes through Nxgyle on the way. We receive no usage reports, and the license is checked offline.
No usage data
There is no telemetry channel in the extension, so the team's code, prompts and usage records stay with you.
No relay
Calls go straight to the selected vendor; when a team runs a local model, they stay on the workstation.
Trade Agreements Act edition
For teams bound by the US Trade Agreements Act, the TAA edition is compiled without restricted model families or providers; no setting adds them back.
Off-limits folders
Leads list paths in the project's ignore file (.nexgileignore), and the agents never read them.
impact before approval
Approvers see what a change touches.
Cortex maps the codebase locally, including which code calls which services. Before an approval, reviewers see what a change is likely to break, with a risk grade between low and critical. The map updates as work proceeds and stays on the workstation.
A local code map
Routes, request flows, subsystems and how far a proposed change reaches, all mapped on the engineer's own laptop, offline.
Translate mode
Legacy code is rewritten file by file in a target language, with every difference marked for review.
Memory across sessions
Project notes are kept between sessions, and searching past chats shows what the team decided and why.
Reads your specs
Word, Excel and PDF specs, plus web pages, can feed a task; if a lead enables it, the agents study other repositories too.
fixed limits
Limits your team can rely on.
Whatever the approval settings, the tool refuses unsafe writes and can hold agents to set folders. On macOS and Linux, switching on the optional sandbox makes the operating system block command writes outside the project.
Checkpoints
On by default, they record file state as the agent works. Restoring one takes a click, though commands already run in the terminal are not undone.
Path limits
Leads restrict which paths the agents may change and can keep automated runs inside named folders; the tooling enforces both.
Sandbox, when you need it
Opt-in on macOS and Linux: the OS keeps command writes inside the project and approved folders, and can block outbound network calls.
Whole files or nothing
The tool refuses partial saves, whether a write was cut off or skipped code with “rest of the file unchanged”.
work allocation
Match each task to a role.
Thirty-one modes come built in, including Plan, Code, Tester, Reviewer and Shipper, each with a narrow remit. Leads give each task the role that fits, and the team can add agents, skills and commands as plain files or from built-in marketplaces.
Thirty-one modes
Alongside ten core modes sit 21 task specialists, for jobs from refactoring to database migration, so each task goes to a fitting role.
Team-made agents, reviewed
Each custom agent is defined in a short Markdown file that the team versions and peer-reviews like any other change.
Shared skills and tools
Skills, meaning reusable instructions, and tool connections install from built-in marketplaces, or the team writes them once and shares them across projects.
Conventions every role follows
Instruction files kept in the repository, including AGENTS.md, hand every role the team's engineering conventions.
review chain
Each change passes through separate hands.
With the Orchestrator on, a coding task is divided by duty. One role or a small team writes the change, two independent roles verify it, and in the standard setup shipping waits on an approval question for the person who owns the task.
01 Code mode or a team
Write
A single coder or a team of 2–5
02 Tester · Reviewer
Verify
Checked in parallel, apart
03 You
Ship?
The task owner answers
04 Shipper
Commit
Main stays untouched
Checkers start fresh
Tester and Reviewer receive only the requirement and the changed files, never the coder's reasoning, and both lack editing tools.
Rework, capped
A failed test or a change request sends the work to a fresh coder; after two retries, the task owner decides what happens next.
One stop for all
A single Stop button halts every agent in the run at once, and a live agent map shows what each one is doing.
Side by side
Agent Manager
Leads follow several AI chats in one view, seeing how far each agent has got, what it has spent and what it is asking.
Side by side
Agent Teams
A larger job can go to two to five agents, for example one on the server side and one on the interface. They coordinate by message and through a task list the team can see.
Side by side
/batch
A broad change is cut into up to 30 tasks that run together, each in its own working copy. Each task can also open a draft pull request (a proposed change) on GitHub for review.
Side by side
/review
Up to five read-only reviewers go over a change together, and fixes begin only on the findings the team picks.
By instruction, Shipper keeps to its own branch and never overwrites a colleague's work. “Ship?” is an approval question. At Supervised and Trust Reads it always waits for a person; further up the dial, only a deny rule keeps a person in the decision.
Team-wide controls
Controls a team lead sets up once.
Approvals, written policy, automated checks and separated duties are configured once, then apply wherever the agents run.
01
Approvals
In the editor, every action waits for a person unless a lead changes the default.
02
Policy rules
Leads write rules that allow, prompt for or refuse an action, and every auto-approval names the rule behind it.
03
Release checkpoint
Agent instructions require a pause before a commit, push, deployment, migration or deletion; adding a deny rule makes it a stop no dial level can skip.
04
Hooks
Team scripts run at chosen lifecycle events and can hold a task open, for example until linting passes.
05
Sealed settings
Agents cannot change the permission, hook or plugin configuration, and the lead agent must ask before editing its own rule files.
06
Segregated duties
Tester and Reviewer have no file-editing tools, so the checkers never become the authors.
Tool access, rules, hooks and the sandbox are code-level controls, not instructions in a prompt.
For your security review
Answers to prepare before rollout.
Expect three questions from your security officer before a team goes live. Who signed off on an action? Where does its cost show up? Which code was within the agents' reach? The answers below show where to look.
Q1
Who approved each action?
Either a team member approved it, or it ran under a rule or setting someone configured, and each auto-approval cites that rule. Have leads record the dial level and policy files per project; editor sessions start in approval mode.
Q2
Where is spend recorded?
As a running estimate on every task, and by day, model and project in the Usage & Cost dashboard, where budget alerts also appear. Agree whether to set per-task caps; a cap that is reached pauses the work for a decision.
Q3
Which code was in scope?
Only what your configuration grants. Bring the rule files that mark actions as allowed, asked or denied. Sub-agents obey the same deny rules, no agent can change the permission or hook setup, and the checking roles cannot edit.
Settings and rule files hold most controls. Keep the rule files under version control next to the code, and your security staff can inspect each one and map it to a control you already run.
Go to the Trust Center the delegation dial
Widen autonomy one level at a time.
A single control under the chat box sets the agents' unattended scope. Start new teams at Supervised, and agree as a team when a project moves up a level.
Note for leads: the dial never switches checkpoints off. Above Supervised, a sub-agent (one agent started by another, such as an Orchestrator role) inherits every auto-approval, though deny rules continue to bind it.
Most review Most freedom
Level 02
Trust reads
The lead lets agents read project files freely, while edits and commands still wait for approval.
- Reads
- Runs alone
- Edits
- Approval
- Commands
- Approval
Level 03
Trust edits
Reads and edits proceed alone. Routine agent questions, even plan approval, default to the first option offered when the 60-second timer runs out; commands still wait. Agree this step as a team.
- Reads
- Runs alone
- Edits
- Runs alone
- Commands
- Approval
Level 04
Trust execution
Reads, edits and commands run alone, and so do tool connections set to always-allowed. Starting sub-agents, writing protected or outside-project files and a few always-ask actions still wait, and deny rules still block.
- Reads
- Runs alone
- Edits
- Runs alone
- Commands
- Runs alone
Level 05
Autonomous
Approvals stop except in three cases: a deny rule still blocks, a protected or outside-project file still prompts, and certain actions, fetching web pages among them, still ask. Keep it for proven work.
- Reads
- Runs alone
- Edits
- Runs alone
- Commands
- Runs alone
Team roles
Who does what in Nx IDE.
Ten core modes, each with one responsibility; the Orchestrator chains several of them on a single task when the team switches it on.
Plan
Drafts the scope and design for the team to approve.
Code
Writes the features and refactors the team asks for.
Chat
Answers the team's questions about the code, without editing.
Debug
Tracks a reported fault to its cause and fixes it.
Orchestrator
Runs coder, checkers and shipper as one chain.
Tester
Tests what another role wrote.
Reviewer
Gives a second review to another role's code.
Shipper
Moves approved work onto its own branch.
Spec Bootstrap
Interviews the team and writes the project wiki.
Spec Sync
Updates the wiki after each commit.
Plus 21 task specialists for routine engineering jobs
RefactorTest GenDoc GenSecurityAPI ModDep UpgradeIssue FixerPR FixerMerge ResolverDocs ExtractorIssue InvestigatorIssue WriterDB MigratorDB ArchitectCode ArchitectDevOpsAPI TesterCode ReviewerTranslateUI DesignerDev
Need another role? The team writes it up in a short Markdown file and makes it available to one project or to all.
Work to delegate
From brief to release, in one tool.
Plan, build, verify and ship in the same editor, at the autonomy level each team has agreed.
Scope and plan
Hand off the first draft of the approach.
- Written plans the team annotates by section
- Architecture sketched before any build
- A wiki that tracks the project
Build and maintain
Features, refactors and upgrades the team assigns.
- Feature work and refactoring
- Modernized APIs and newer dependencies
- Legacy code, translated file by file
Verification
Defects caught before release.
- Each change gets new tests
- Close-out with self-review and a test run
- Tests run by a role other than the author
Review to ship
Independent review, then an approved release.
- /review: five reviewers at once, at most
- Edits shown for approval in the editor
- Ships to its own branch after asking
Knows the codebase
Project-wide context for every task.
- Cortex: routes, flows and impact, mapped locally
- Memory between sessions, searchable chats
- Semantic code search, once set up
Fits your toolchain
Works with the tools your engineers already run.
- Connections to outside systems and tools
- One-click skills and tools from the marketplace
- Optional: opens the built app locally to check it runs
Under your controls
Speed within the limits your leads set.
- Approvals first in the editor; the dial sets the rest
- Written policy and hooks that can block
- Opt-in OS-level sandbox (macOS, Linux)
- Budget alerts, shown in Usage & Cost
Parallel delivery
One chat, or many agents in parallel.
- Agent Manager: side-by-side chats
- Coordinated teams of 2–5 agents
- /batch: 30 isolated tasks at most
Fits daily work
Fits the habits your engineers have.
- One-click restore from any checkpoint
- Autocomplete and dictation, if switched on
- Plain language → shell command
- Chat in VS Code or in a browser
What's new
Added this release.
- Scale
Teams, Manager and /batch for parallel work
The team can run agents side by side and split jobs across small agent teams. A large change can run as parallel tasks, each able to open a draft pull request.
- Scoping
Plan comments and /review
Reviewers comment on plans before anything is built, and /review puts up to five reviewers on a change at once.
- Safety
Rule-based policy, hooks, a sandbox
Leads can allow, prompt or deny by rule, attach scripted checks to lifecycle events, and turn on an operating-system sandbox on macOS and Linux.
- Knowledge
Project memory, web reading, spend views
Memory that lasts across sessions, research across documents and the web, and a cost view that splits spend by model and by project.
- Providers
New vendor models
Recent releases from the major vendors are now selectable.
Before rollout
What your team must enable.
Opt-in — off until a lead enables it
- Operating-system sandbox (macOS, Linux)
- Per-task request and spend caps
- Web search and research in other repositories
- Opening the built app in a browser to check it (needs Chrome or Edge)
- Automatic note-taking in project memory
- Inline completion and read-aloud; voice dictation too, which needs FFmpeg and a transcription key
One-time setup before use
- Semantic search over the codebase
- Tool connections, either team-built or from the marketplace
Straight answers
What delivery managers ask us.
Short answers for planning a rollout.
Ask us something elseCan it act without approval?
Only where your leads allow it.
Editor sessions require approval by default, and rules plus the dial level set what proceeds alone; above Supervised, sub-agents inherit that freedom within your deny rules. The command-line runner auto-approves unless started with approval required, so decide who may use it.
Can we cap AI spend?
Yes, if a lead sets one.
Spend appears as a running estimate; budget alerts are warnings only, and an optional per-task cap puts the task on hold for a decision.
Which models can teams use?
Over 20 providers, or models running entirely on your own hardware.
The TAA edition leaves out restricted-origin providers, and local models keep source code on your premises.
Will Nxgyle hold any of our code?
No.
The extension has no telemetry and Nxgyle operates no relay, so your code reaches just the vendor your team selected.