Clarify agent ambient runtime vs agentd managed capability enforcement

Problem

agent and agentd currently share YAML frontmatter parsing, but runtime semantics are implicit:

• agent behaves like a direct CLI interpreter and runs with ambient shell/process capabilities.
• agentd supervises managed runs (containers/systemd) and applies runtime constraints.

Users are confused about whether frontmatter/runtime fields are enforced in plain agent runs, especially for PATH/network/capability expectations.

Decision (Design)

1) Runtime boundary

• **agent is ambient**: inherit environment/capabilities from parent process (Unix interpreter model, including shebang workflows).
• **agentd is managed**: enforce runtime constraints/capability restrictions.

2) Frontmatter semantics

Keep one shared frontmatter format, but clarify field classes:

• Agent fields (always applied by agent): provider/model/budget/tools/system_prompt/imports.
• Managed-runtime fields (enforced by agentd only): toolchain/workspace/assertions and future runtime policy fields.

For direct ambient agent runs, managed-runtime fields are advisory metadata and not enforced by agent.

3) Execution context signaling

Introduce explicit execution-context signaling from agentd to agent:

• AGENT_EXECUTION_CONTEXT=agentd for runs launched by agentd (container/daemon/persistent).

This lets agent distinguish ambient vs managed execution without guessing from PATH/process ancestry.

4) UX/observability

When running ambient agent with managed-runtime frontmatter keys present:

• emit a concise stderr note that those fields are advisory in ambient mode and enforced by agentd.

No behavior breakage for existing shebang/direct workflows.

5) Forward-compatible schema

Extend shared WorkflowMeta with optional runtime-policy keys for future managed enforcement/discovery:

• runtime_profile (optional)
• requires.commands (optional list)
• requires.network (optional list)

These keys are parsed now, documented, and treated as advisory in ambient agent runs.

Implementation Plan

1. Extend WorkflowMeta parser to include runtime_profile and nested requires. 2. Add ambient-mode advisory warning in agent when managed/runtime-policy keys are present and AGENT_EXECUTION_CONTEXT != agentd. 3. Set AGENT_EXECUTION_CONTEXT=agentd for all agentd-launched paths:

• oneshot container flow
• workflow container flow
• persistent systemd units
• daemon spawned direct processes

4. Update docs (Omni/Agentd/SPEC.md) to codify ambient-vs-managed boundary and field semantics. 5. Add/adjust tests for parser and runtime-wrapper/systemd template expectations.

Acceptance Criteria

• Direct agent ./prompt.md continues to run ambiently (no sandboxing added).
• Managed-runtime/frontmatter fields do not hard-fail ambient runs.
• Ambient runs print clear advisory when such fields are present.
• Agentd-launched runs identify as managed via AGENT_EXECUTION_CONTEXT=agentd.
• Docs clearly state enforcement boundaries between agent and agentd.