1. What is a code?
In Agent OS, a code means a software package or executable tool: commercial software, open-source software, free software, a command-line program, a Python package, a WSL tool, a script, a database, or a SaaS tool with a usable API or automation path.
The important point is that a code is not merely listed. Each code/software package is paired with its own dedicated agent on a 1:1 basis, so the software has an operating agent that understands how it is launched, documented, checked, and used.
2. Who chooses what codes Agent OS uses?
The human customer chooses. Agent OS is meant to support the tools a real person, lab, business, or engineering group already uses, plus the tools they want to add. RaNDTek can provide pre-populated discipline suites and expert setup help, but the product is not designed to trap users inside one vendor's software list.
For enterprise use, the code list can be governed by the customer's IT, security, procurement, and subject-matter experts. The operating idea is simple: the user chooses the software stack, Agent OS binds it, and each bound code receives a dedicated operating agent.
3. What codes can I use with Agent OS?
Agent OS is intended to work with any code installed on the user's machine, and with SaaS systems that expose a practical API or automation route. The user is not restricted to a narrow list of pre-bound codes for a discipline.
Pre-populated discipline suites can ship with common codes already organized, but customers can also bind their own software, scripts, databases, references, and local tools, subject to licensing, credentials, permissions, and security policy.
4. How does Agent OS bind a new code?
Code binding connects a software package to a discipline slot and gives it the context it needs to become usable by agents. The binding path can locate an installed tool, validate how it is detected, assign it to a genre/channel slot, update registry information, create prompts, create best-practices files, and make the code visible to teams and workflows.
The architecture supports practical detection paths such as executable lookup, direct file existence, Windows registry checks, WSL probes, Python package imports, and user-asserted installs for tools that are real but difficult to probe automatically.
5. Why are literature RAG and databases important?
Codes are only part of serious work. Technical work also depends on manuals, papers, standards, textbooks, procedures, prior reports, local notes, customer documents, and structured data. Agent OS treats literature RAG and databases as first-class operating resources, not as afterthoughts.
A bound code becomes far more useful when its dedicated agent can see the relevant documentation, local literature, custom databases, prior project files, best-practice files, and discipline-specific knowledge. Customer data, files, databases, and internal documents can be searched and privately folded into workflows on the customer's machine or controlled environment. Stored and updatable literature RAG can influence how Agent Teams plan work, how the Workflow Builder structures task paths, which codes are used, what validation steps are expected, and how results are reviewed.
That is how Agent OS turns software into a working discipline instead of a loose pile of tools.
6. What is a 1:1 software-agent pair?
Each supported software package, code, script, function, or tool channel can have a dedicated guiding agent. That agent carries the context needed to operate the tool: launch path, allowed files, documentation, command patterns, best-practice files, registry entries, prompts, output expectations, and failure notes.
Those software-agent pairs become reusable building blocks. They can be assigned into Agent Teams or placed as subagents inside structured workflows. This is the central operating pattern: thousands of software packages, one Agent OS, one dedicated agent for every software package.
7. Is it easy to add codes or suites of codes?
Yes. Entire code suites can be installed, detected, bound, and organized automatically where licensing, installer permissions, and customer policy allow. A customer can start with a prepackaged discipline suite or create a new discipline by naming the software stack, literature, databases, procedures, and outputs involved.
A suite can include genres, bound codes, databases, literature imports, prompts, best-practices files, detection rules, workflow templates, and final validation scans. Agent OS can search for help and documentation, surface it, extract the useful operating material, and make it available to the system. The user should not have to become an integration engineer just to make serious software work together.
8. How do you run a code?
You can run a code by talking to its dedicated agent, by using Agent OS controls, by using an API path where appropriate, by having your favorite external coding agent operate Agent OS through the API, or by running multiple codes together in a coordinated way through Agent Teams and free-form or structured workflows.
The goal is not one-code-at-a-time automation. The goal is to run as many software packages and dedicated agents as the task demands, all at once when useful, coordinated through the operating layer while the human stays in control of setup, permissions, and review.
That matters because an outside agent does not have to become a custom integration for every piece of software. It can ask Agent OS to route work to the many dedicated agents inside Agent OS: one outside agent supervising, requesting, or coordinating many internal software-agent pairs, teams, and workflows, subject to permissions and review.
9. How do you build a workflow?
A workflow can be built by talking to the Workflow Builder agent or by manually creating workflow nodes, edges, decisions, notes, references, pause gates, subagent assignments, required deliverables, and review points.
The point is flexibility. A human can sketch the problem in plain English and let the Workflow Builder agent propose the structure, or a technical user can manually author the structure when the procedure is already known.
10. How do you instruct an agent or a team?
You instruct an individual agent by talking to it directly. You instruct an Agent Team by talking to the team's DRI agent, the directly responsible coordinating agent, and by giving the team documents that define the problem statement, constraints, files, expected outputs, and review criteria.
Agent OS is designed around explicit work artifacts. The user can type instructions, attach or point to documents, let agents read local files, use stored literature RAG, and let the team convert the problem statement into tasks, software actions, validation steps, and deliverable documents.
11. What is Agent OS technically?
Agent OS is a desktop operating layer for intelligent software interlinking. The human states the mission in plain English, chooses a discipline or workflow, and Agent OS coordinates software packages, local files, prompts, references, dedicated agents, Agent Teams, subagents, execution steps, logs, and review gates.
The goal is not a single chatbot. The goal is an operating surface where many agents can operate many software packages together while the human remains in control of setup, permissions, review, and final approval.
The deepest technical idea is the combination: one dedicated agent per software package, modular discipline packs, stored and updatable literature RAG, custom databases, free-form work, structured workflows, Agent Teams, and human review. Agent OS turns software from isolated applications into coordinated operating members of a larger agent-driven desktop system.
12. What is a free-form workflow?
A free-form workflow is plain-English work with less rigid structure. The human states the goal, opens the relevant discipline, and Agent OS lets the appropriate agent or team reason through the best working path.
This is valuable for exploration, first-pass research, setup, debugging, new use cases, and tasks where the exact procedure is not known yet. Free-form work can later be converted into structured workflows when the pattern becomes repeatable.
13. What is a structured workflow?
A structured workflow is a saved, repeatable task graph. It can define stages, decisions, notes, references, code assignments, pause gates, working folders, required deliverables, subagent bindings, expected artifacts, review points, and final packaging.
This is the serious-work mode for tasks that need repeatability: engineering, accounting, trading analysis, scientific computing, technical legal support, documentation, validation, and other workflows where outputs must be traceable and reviewable. Structured workflows are especially important for iterative, looping problems that need to converge: run, inspect, revise, rerun, validate, and package the final result.
14. What are subagents, and what kinds exist?
Subagents are dedicated agents assigned to parts of a structured workflow. They can operate software, prepare data, run calculations, inspect results, search references, validate outputs, write summaries, build reports, package deliverables, or perform security and quality checks.
Agent OS supports subagents that work in serial or in parallel. In mandatory-wait mode, the master waits for the subagent result before continuing. In mandatory-parallel mode, the subagent works alongside the master and returns its deliverable when ready. Subagents can be powered by different agent channels, such as Codex, Claude Code, future Gemini paths, enterprise agents, or local agents as those mature.
15. What is an Agent Team?
An Agent Team is a fixed group of software-agent members assigned to a project, with a DRI agent responsible for coordination. Team members can be software operators, researchers, validators, writers, security reviewers, report builders, or other role-specific agents.
Agent Teams are built for cooperative work. They create project artifacts, communicate through explicit files, move through visible phases, and keep responsibilities and outputs inspectable instead of letting the work disappear into a single chat thread.
16. Agent Team vs. structured workflow: what is the difference?
An Agent Team is a coordinated workgroup of agents. A structured workflow is a repeatable operating procedure with nodes, edges, decisions, subagents, deliverables, and review points.
In simple terms: teams are organized workgroups, while structured workflows are reusable task maps. Complex work can use either pattern, or both, depending on whether the task needs open collaboration, strict sequence control, parallel subagent execution, or repeatable procedure.
17. How does Agent OS run software without writing a custom integration for every code?
Agent OS uses the coding agents themselves as the universal adapter. The per-code artifacts provide the what and where: launch paths, documentation, registry entries, prompts, best-practice files, examples, source references, and known procedures. The coding agent's tools provide the hands: shell access, file reading and writing, scripts, Python, COM or automation bridges, and source inspection when allowed.
This documentation/source-driven integration is the only practical way to support a long tail of software. Writing and maintaining a bespoke adapter or MCP server for every piece of software on Earth would be prohibitively expensive.
18. Does Agent OS use MCP servers?
MCP servers can be useful for selected high-risk or high-value tools where a narrow, typed, audited interface is worth the maintenance burden. But MCP is not the core scaling mechanism for Agent OS.
For the long tail of software, Agent OS deliberately uses coding agents plus strong context and containment. For critical surfaces, MCP servers or fixed wrappers can be added selectively.
The reason is scale. Writing and maintaining an MCP server for every software package Agent OS may run would be prohibitively expensive. Agent OS instead uses the coding agents themselves as the universal adapter: per-code artifacts provide launch paths, documentation, registry facts, prompts, best practices, and allowed procedures, while the agent's tools provide the hands. MCP also does not make a system secure by itself; safety comes from permissions, sandboxing, containment, logs, and review gates.
19. Is there an API, and does it help?
The current architecture includes an internal automation and diagnostics API used for setup, workflow, team, subagent, binding, validation, and test operations. The key engineering point is parity: API paths are intended to route through the same services as the GUI, not through a separate behavior path that can drift away from the product.
A supported API can help enterprise deployment, repeatable setup, quality assurance, diagnostics, automated discipline provisioning, and integration with controlled customer infrastructure. The desktop interface remains the human operating surface; the API helps make the product testable, automatable, and maintainable.
20. Where do customer files stay?
Customer files stay local to the machine, workstation, or controlled environment where Agent OS is running. Agent OS is designed as a desktop operating layer, not a remote SaaS workspace that uploads and stores customer files on RaNDTek servers.
Cloud AI or external services may be used when the customer chooses that mode, but the product direction is local-first: local files, local software, local workflows, and human-controlled review.
21. Is Agent OS a SaaS product?
No. The intended direction is desktop-first. The software, project folders, intermediate artifacts, review materials, discipline files, and local tools remain under local operator control.
Agent OS can still use cloud AI accounts, coding-agent CLIs, enterprise AI, APIs, or local models when those are the right tool. The workspace itself is not intended to become a remote SaaS environment.
22. What AI providers can it use?
The demo uses Claude Code from Anthropic and Codex from OpenAI. Gemini CLI is also available as a Google flagship-agent path, and the architecture is intended to remain provider-flexible.
The direction is agent-agnostic: Claude Code, Codex, Gemini CLI, future commercial agents, enterprise agents, local agents, and Ollama-class local model paths can all become operating channels inside the same desktop layer.
NVIDIA Nemotron-class models and similar enterprise or open model families can also be used as backend model options where the runtime and agent path fit the task. In that role, Nemotron is not the operating layer; it is one possible model brain that Agent OS can assign to agents, software bindings, literature/database work, local inference, enterprise deployment, or specialized discipline channels.
23. Do NVIDIA PhysicsNeMo, CUDA-Q, or similar platforms replace scientific and engineering software?
No. NVIDIA PhysicsNeMo is a physics-AI framework for developing physics-ML models, surrogate models, and real-time prediction workflows from simulation and observed data. CUDA-Q is a hybrid quantum-classical programming model and toolchain for running quantum, CPU, and GPU resources together. These are powerful scientific computing platforms, but they are not universal replacements for validated engineering and scientific software.
AI surrogate models, physics emulators, neural operators, and related inference-based methods can be extremely useful because they can approximate expensive numerical calculations much faster than rerunning a full solver every time. But they are accelerators and screening tools, not automatic final authorities. In serious engineering, science, finance, medicine, or safety-critical work, their outputs still need validation against trusted solvers, measured data, uncertainty checks, standards, and expert review. You can use a physics emulator to explore a design space quickly; you should be very cautious about getting into a car, aircraft, medical device, bridge, or roller coaster whose final safety case is only that an inference model said it looked fine.
In Agent OS terms, PhysicsNeMo, CUDA-Q, Nemotron, Omniverse, CUDA libraries, commercial solvers, open-source codes, and customer scripts are all potential bound tools, model channels, or workflow nodes. Agent OS does not assume that AI replaces any form of technical or quantitative software, validated domain software, accounting systems, databases, or other trusted customer tools. The product thesis is the opposite: those tools become more valuable when agents can operate them, connect them, compare them, document them, and coordinate them with other software under human review.
24. How does Agent OS control AI cost?
Agent OS is designed to avoid forcing long multi-agent workflows through API-token-only charging. Serious work can involve many agent actions, file passes, code reviews, retries, reports, subagent exchanges, and validation steps. Metering all of that through API tokens can become orders of magnitude more expensive than CLI- and subscription-based operation.
The preferred model is to use the customer's chosen OpenAI, Anthropic, Google, enterprise, or local accounts through coding-agent CLIs where possible, reserving direct API usage for cases where it is truly the right tool.
25. How does Agent OS approach security?
Security comes from containment and operator control, not from a single magic adapter. The demo shows deterministic restrictions: network drives can be disconnected by demapping them, intranet access can be blocked with firewall rules, and selected local drives can be restricted. Virtual machines can add another layer of isolation.
NVIDIA OpenShell is being added to the security-option roadmap as an additional runtime-containment path for agent execution. It fits the Agent OS security model as another possible profile for isolating agent processes and controlling filesystem access, network egress, credentials, logs, and operator-visible policy.
The sandbox and permission systems in coding-agent CLIs are also evolving. Product hardening will continue for the lifetime of Agent OS: stronger boundaries, profiles, logs, review gates, testing, and safer multi-agent execution.
No AI system can honestly be described as 100% secure unless it is used in an artificial condition, such as a physically isolated computer with no external services. Agent OS treats security as a permanent engineering discipline: constrain what agents can reach, make their actions visible, require human review where appropriate, and keep hardening the product as the CLI sandboxes, local-agent options, virtual-machine deployments, and enterprise controls improve.
26. How many agents can it coordinate?
The current Agent OS design can deploy roughly 260 agents simultaneously across tasks. The exact useful number depends on the task, discipline, machine, tools, account limits, sandbox settings, and whether work is serial, parallel, or mixed.
The point is not raw agent count by itself. The point is controlled coordination: agents assigned to real tools, real files, real workflows, and real review gates.
27. How does Agent OS support quantitative correctness?
For engineering, science, accounting, trading analysis, and other quantitatively sensitive work, Agent OS is intended to coordinate real calculation codes, controlled inputs, repeatable workflows, best-practice files, validation steps, logs, and human review gates.
The goal is not to trust a loose chat answer. The goal is to have agents operate real software, produce artifacts, preserve context, and make outputs reviewable by a human expert.
28. What artifacts does a workflow produce?
A workflow can produce plans, task files, intermediate data, scripts, logs, cleaned inputs, plots, reports, summaries, captions, movies, review notes, rerun instructions, PowerPoint decks, Word deliverable documents, and final packages at any level of detail requested: executive summary, technical appendix, full audit trail, or complete reusable work packet. These artifacts are part of the product idea: work should be persistent, inspectable, and reusable.
29. What is a discipline pack?
A discipline pack is a modular workspace for a field: software packages, code slots, dedicated agents, references, standards, prompts, best-practice files, workflows, examples, and review expectations. Customers can buy populated discipline suites or start with a general Agent OS and populate their own disciplines.
30. How does Agent OS improve with use?
Agent OS develops local operating memory: workflow files, best-practice files, software-control files, discipline databases, custom databases, stored and updatable literature RAG, internal documents, review patterns, and agent instructions. Over time, the local environment becomes tuned to the customer's software, files, standards, repeated tasks, and preferred outputs.
31. Does it run on Windows, Linux, and macOS?
The current demo was developed under Windows. There is no fundamental constraint preventing Agent OS versions for Linux or macOS. Cross-platform support is an engineering roadmap issue, not a conceptual limitation of the operating model.
The operating idea is portable: bind software, assign dedicated agents, organize disciplines, run workflows, preserve artifacts, and maintain human review. The platform-specific work is ordinary product engineering: installers, file paths, process launch rules, permissions, shell behavior, package managers, GUI automation, sandbox profiles, and OS-specific detection paths.
32. What remains on the technical roadmap?
Major work includes product hardening, installer and update flow, cross-platform packaging, stronger security profiles, better logs, workflow versioning, discipline-pack tooling, alpha-test feedback loops, support documentation, local-agent paths, and selected narrow integrations for high-risk tools.
33. Does Agent OS replace human beings?
No. Agent OS uses flagship coding agents as operating channels, but the product is designed to augment human experts, not replace them. The human still frames the problem, chooses the discipline or workflow, defines constraints, checks outputs, asks for supporting evidence, and approves the final result.
Flagship coding agents such as Codex and Claude Code are strong at connecting software, reading and writing files, running tools, creating glue scripts, coordinating subagents, producing reviewable artifacts, and moving work through structured or free-form workflows. They are not yet reliable stand-alone designers. In mechanical design, optics, architecture, engineering, and other visual or spatial domains, they can make frequent errors because they do not reliably see, rotate, pan, zoom, measure, and interrogate live 3D or graphical outputs the way a trained human expert does.
The technical point is that Agent OS lifts the burden of making many software packages talk to each other. Once that burden is reduced, a human designer, engineer, scientist, analyst, or operator can become more multi-functional across genres of a discipline. Agents handle connection, execution, documentation, and packaging; the human supplies judgment, taste, domain knowledge, validation, and final authority.
34. How is Agent OS different from Microsoft Foundry?
Microsoft Foundry is for building and operating managed AI applications and agents inside Azure. A typical use case would be a company building an internal cloud AI assistant that uses Claude or another model, searches SharePoint and Azure AI Search, calls approved company APIs, opens tickets, follows Microsoft Entra/RBAC permissions, and gives IT teams monitoring, logging, evaluations, networking, policy control, and governance.
That is valuable cloud infrastructure, but it is not the same product category as Agent OS. Foundry answers: how does an enterprise build, host, secure, and monitor an AI app or managed agent in Azure? Agent OS answers: how does a human expert make many real software packages, local files, documents, databases, discipline packs, literature RAG, structured workflows, Agent Teams, and flagship coding agents work together on a desktop or controlled machine?
The difference matters most in complex, technical work. Agent OS is not just trying to host an agent. It is trying to coordinate the actual software stack used by a human expert: CAD, FEA, CFD, Python, MATLAB, spreadsheets, chemistry codes, quantum codes, optics tools, trading tools, accounting tools, media tools, local databases, standards, papers, and project files. Each supported software package can have a dedicated 1:1 operating agent, and those software-agent pairs can become members of Agent Teams or subagents inside structured workflows.
Foundry can be an important cloud AI platform that Agent OS may use or interoperate with. But Foundry is cloud AI infrastructure. Agent OS is pursuing the missing desktop layer: local-first software coordination, discipline modularity, customer-controlled files, reusable workflow artifacts, and human-reviewed execution across arbitrary software, including software that was never designed to live inside a cloud agent platform.
