Skip to main content

OS portal

The OS portal is the boundary between agents and the workspace. Agents use the portal to understand what is available and to run approved skills. The portal keeps the product surface small: one path for context, one path for action.

Why the portal exists

The portal gives agents a structured path to context and approved action, so workspace work stays organized around artifacts, implementation scripts, and connected capabilities. The portal should answer:
  1. What workspace am I operating in?
  2. What should I know before doing work?
  3. Which skills can I run?
  4. Which capabilities are connected?
  5. What guardrails apply?
  6. How do I return a traceable result?

Portal responsibilities

ResponsibilityWhat OS should do
ContextReturn workspace identity, product language, available skills, capability health, and relevant rules.
ActionRun a named skill with validated input.
GuardrailsPause high-impact actions for human approval.
ObservabilityAttach trace IDs, execution records, logs, and artifacts.
Capability checksTell the agent when a skill cannot run because something is not connected.
Output contractsReturn structured results instead of untracked free-form output.

Context entry point

The context entry point should return enough steering for an agent to behave correctly. Useful context includes workspace name, runtime mode, available skills, required capabilities, capability health, artifact storage mode, approval rules, links to deeper docs, and recent execution summary when relevant. Context should be compact. It is not a dump of the entire workspace.

Action entry point

The action entry point should run approved skills. A call should include the skill name, validated input, and whatever workspace or user context OS already knows. The agent should not have to pass every identity or storage detail manually. The action result should include status, trace ID, skill name, summary, artifacts, approval state when relevant, and safe error information when something fails.