# AI System ## Status An initial provider-neutral AI service, supervisor planner, typed tool registry, OpenAI Responses adapter, and durable Core API execution/step records are implemented. The adapter requests a strict `SupervisorPlan`, disables provider-side response storage, sends only a hashed safety identifier, and never treats a plan as proof that a tool ran. Missing credentials remain `unconfigured` and a planning attempt becomes a durable `blocked` execution rather than simulated success. The only registered tools are low-risk read contracts for explicit system status and authorized workspace profile state. Core can execute those tools for the original actor with current reauthorization, schema checks, dependency ordering, timeouts, verified checkpoints, cancellation, audit, and idempotent completed-run replay. The persisted Agent Builder backend now owns versions, tool/permission grants, autonomy, schedules, hierarchy, limits, lifecycle, and delegation requests. The authenticated Agent Studio UI and owner-managed OpenAI model-routing catalogue are implemented. Memory retrieval, streaming, queues, measured costs, capability-aware fallbacks, write tools, and final answer synthesis are not implemented yet. ## Control-plane principle Models propose; the application authorizes and executes. LLM output is untrusted structured input. The Core API owns identity, workspace scope, permissions, policy decisions, approvals, durable execution state, and audit. The target AI Agent service owns orchestration and provider interaction but cannot grant itself permissions or directly claim an external action succeeded. ## Orchestration flow 1. Persist the authenticated user instruction as an execution. **Implemented.** 2. Build authorized context from workspace data and bounded memory retrieval. 3. Ask the supervisor for a typed plan referencing registered tools. **Implemented.** 4. Validate the plan schema, tool registration, argument schema, and dependency DAG. **Implemented.** 5. Reevaluate each proposed action in Core using current permissions, autonomy, and risk. **Implemented for the two read-only tools.** 6. Deny, draft, request approval, or create an authorized action intent. 7. Dispatch through the outbox to the owning tool worker. **The two current Core-owned reads execute synchronously; queued dispatch is not implemented.** 8. Verify observed external state and persist the outcome. **Implemented for the two reads.** 9. Append audit/execution records and update memory only under an explicit memory policy. **Audit and execution checkpoints are implemented; memory is not.** 10. Return an evidence-based summary that distinguishes success, failure, and uncertainty. Plans are revisable data, not private reasoning logs. The system stores concise rationale, tool inputs/outputs as allowed, evidence, and state transitions; it does not require or expose model chain-of-thought. ## Provider abstraction The provider interface currently supports typed plan generation. Its target also includes streaming, vision, embeddings, and realtime voice as separate capabilities. Configuration resolves by workspace and agent and includes provider, model, fallback, reasoning level, temperature where supported, output limit, timeout, and budget. Provider-specific identifiers remain behind adapters. The OpenAI adapter uses Responses with Pydantic structured parsing; the configured model is operator-supplied and never hard-coded. Workspace model profiles persist routing metadata only: a stable profile key, display name, provider, model identifier, enabled state, and declared capabilities. Agent create/update validates preferred and fallback references against enabled profiles in the same workspace. Core resolves the selected model identifier for each planning request, while provider credentials remain deployment secrets owned by the isolated AI service. Fallback is allowed only when capability, data residency, policy, and cost constraints permit it. Timeout or provider failure never turns an unexecuted action into success. The current execution records capture provider/model and token usage. Prompt versions, latency, and cost capture remain required, without logging secrets. ## Runtime agents and delegation Each agent is now a persisted workspace-owned entity with independent identity, instructions, model configuration, tools, permissions, memory scope, autonomy, working schedule, budget, concurrency, status, and execution history. The initial schema/API implements model-profile validation but not memory scope, measured budget/concurrency enforcement, or filtered execution history. An agent type is not merely a prompt label. The initial user-mediated delegation request receives only the intersection of source agent, target agent, actor, and platform permissions. It creates a durable audited record and cannot cross workspaces or bypass approval. Supervisor dispatch, execution linkage, delegation-cycle limits, and bounded depth remain required before an agent can perform delegated work. ## Tool registry and contracts Tools declare a stable name/version, typed input/output schema, owning service, required permission, read/write classification, base risk, idempotency capability, timeout, and verification strategy. Registration does not authorize use. The AI service checks its allow-list, and Core independently maps each proposal back to its server-owned permission/risk policy before persisting steps. Core does the same check again immediately before execution and automated tests detect security-metadata drift between the AI and Core copies of the registry. The policy decision is bound to the canonicalized tool request and policy version. A materially edited request is reevaluated. External-write workers require an authorized action grant and idempotency key, checkpoint progress, and return evidence plus one of succeeded, failed, or unknown. ## Policy and approvals The current evaluator fails closed for missing permissions or disabled agents, restricts Observe and Draft writes, requires approval for high risk, and permits lower-risk writes only at Controlled Autonomous or Autonomous levels. It is a tested kernel, not the full policy engine. The complete engine must additionally evaluate actor membership, resource/contact constraints, working hours, budgets, emergency stop, integration health, data sensitivity, approval rules, and current platform policy. High-risk actions always require explicit approval. Approval snapshots show exact intended content and expire; broad grants are never inferred from one approval. ## Memory and grounding Memory is not implemented. Target memory types include short-lived execution context, durable user- approved facts/preferences, and source-backed retrieval records. Every memory is workspace scoped, has provenance, sensitivity, retention, and deletion metadata, and can be excluded from an agent's scope. Retrieved text is evidence, not instruction authority. Responses about calendars, messages, calls, or external state cite tool evidence internally and must not invent missing records. If a source cannot be queried or an action cannot be verified, the user- facing result states that limitation. ## Prompt-injection and tool safety - System/developer policy and registered tool schemas outrank content from websites, messages, emails, documents, and tool output. - Untrusted content cannot modify permissions, request secrets, redefine the task, or authorize a side effect. - Tool arguments are schema validated and constrained by server-side allow-lists; URLs and file paths receive SSRF/path-boundary checks in their owning services. - Read results and proposed writes are separated. Sensitive or financial language raises risk rather than lowering it. - Repeated failures stop or escalate; they do not cause blind retries of side effects. ## Human control and recovery Pause, takeover, permission revocation, and emergency stop are durable application state checked before dispatch and at worker checkpoints. Browser tasks use an exclusive lease with fencing. Each step records goal, expected state, last verified state, attempt, and error so recovery begins by observing, not repeating an uncertain write. ## AI readiness gate AI functionality is not ready until provider configuration is encrypted and health-reported, provider adapters and typed tools are tested, policy/approval checks are integrated, execution and outbox persistence exist, prompt-injection tests pass, costs are captured, external writes are idempotent and verified, and stop controls are proven end to end.