Skip to main content
The current repository is a local-first MVP. These boundaries are intentional and should shape integrations:
  • PostgreSQL is the only application database. OAO has no Convex or Redis dependency. Event webhooks can push product events to a receiver you run, such as a Convex HTTP action, but OAO never reads state back from it.
  • The TypeScript SDK is a private workspace package. OAO applications inside this monorepo can depend on @oao/sdk-js with workspace:*. External codebases should use the documented HTTP/SSE contracts until the SDK is published or distributed from a registry you control.
  • Run files are deliberately bounded. Initial and later turns accept up to eight UTF-8 text/code/data files, supported images, PDFs, common Microsoft Office/OpenDocument/iWork documents, or EML/MSG emails. OAO uploads the original bytes to the project’s default S3-compatible storage provider and copies them into a sandbox without extraction, OCR, or format validation. PostgreSQL stores only the run manifest, not file bytes or extracted text. A configured default storage provider and sandbox-enabled agent are therefore required; binary formats require shell and suitable software in the selected image or snapshot. Standalone archives, audio, video, Access/Publisher/OneNote/Visio/Project files, and arbitrary binaries are not accepted. Files are submitted inline as base64 through the API; browser-to-object presigned uploads and reusable artifact references remain future work. For full codebases, use narrow caller-owned read/search tools instead of attaching the repository.
  • One run executes at a time per session thread. Submit the next turn only after the latest run is completed, failed, cancelled, or timed out.
  • Harness Operations inherit the entire parent capability catalog. An Agent version can publish up to 32 focused scratch loops. They reuse the parent model, rendered instructions, tools, all mounted Skills, and live sandbox; V1 has no per-operation model, capability, sandbox, or Skill binding. Flue does not currently support per-harness Skill scoping, so every operation sees the Agent’s full Skill catalog. Operations are temporary, cannot call other Harness Operations, and do not create standalone child Agent records or persistent OAO sessions. Flue retains the internal child-conversation record for durability. A crash after model completion but before a step.do checkpoint commits may repeat that model work. OAO adds no scheduler or file-locking layer for sequential/batched operation calls that share the workspace.
  • Delegate rosters are publication-time and exact. A coordinator version can pin up to 32 child versions and allow 1–8 parallel calls per delegate. OAO creates persistent child sessions and shares the root Daytona workspace, but it does not dynamically discover agents, mutate a published roster, merge child conversation histories, move a child to another workspace, or distribute orchestration across different sandbox providers. Parallel child writes to the same files require application-level coordination; OAO does not provide file locks or merge resolution.
  • Skill packages are inline and PostgreSQL-backed. Each request is limited to 128 resources, 5 MiB per resource, and 10 MiB total expanded content. There is no archive, Git registry, object-storage upload, cross-project sharing, signature service, or automatic remote update workflow. Skills are not materialized into Daytona workspaces; Flue reads verified resources from the runtime registry. Files under scripts/ are never run automatically, and allowedTools is informational rather than a policy control. Skills can be disabled (reversible) or removed, but removal archives rather than deletes: published versions and bindings stay stored for existing agent versions and session history.
  • Runtime execution requires a configured model provider. Add an organization-shared OpenRouter, OpenAI, Anthropic, or xAI provider connection and approve a project preset before publishing an executable agent version. Daytona is required only for sandbox-enabled versions, and S3-compatible storage is required only for run files and workspace backups. Test doubles are not selectable in the API or console.
  • Model presets are append-only. A project:admin principal can approve a new project preset from the provider catalog, duplicate an existing one into a new key, and archive one so new agent versions stop seeing it. There is no rename or repoint route and no reviewer approval workflow; archived presets keep resolving for already published agent versions.
  • Provider credentials are organization-scoped encrypted records. API keys, model providers, storage providers, sandbox providers, and MCP servers/credentials/policies are shared by every project of the organization. The console can create connections, rotate write-only keys, and remove a connection once no live preset routes through it (the key is wiped). The API never returns a key, and encryption-key-ring rotation is not included in this MVP.
  • Upgrading to organization-shared credentials requires re-entering secrets. The AES-256-GCM authenticated encryption context no longer binds a credential to one project, so model provider API keys, storage provider credentials, MCP credentials, and Daytona credentials stored before the organization-sharing release cannot be decrypted afterwards. Rotate or re-enter each one after upgrading.
  • Project deletion is a hard delete that skips object storage. Deleting a project permanently removes its PostgreSQL records — including runs, product events, and the audit trail — and its Flue conversation state, but leaves workspace-backups/threads/... and run-files/runs/... objects in the S3-compatible store for operators to clean up. The active project and the organization’s last project cannot be deleted.
  • Project switching is cookie-scoped. The console switches projects with POST /auth/switch-project, which sets an oao_active_project cookie for the browser; other devices and existing bearer sessions keep their own active project. API keys act on any project through the URL path.
  • Remote MCP is HTTPS and static-credential only. OAO supports Streamable HTTP and legacy SSE with static bearer or safe API-key headers, immutable discovery snapshots, restricted toolsets, and exact-origin credential injection. Stdio, OAuth/refresh, dynamic client registration, per-user delegated credentials, automatic retry of outcome-unknown calls, and sandbox secret substitution are deferred. Tool results are untrusted remote content; OAO bounds and validates them but cannot prove they are free of prompt injection.
  • Workspace backup stores only the latest archive per thread. OAO backs up the active Daytona workdir to the configured S3-compatible provider, but historical rollback requires bucket versioning and there is no generation browser. The 512 MiB compressed and 2 GiB expanded limits are enforced. Archive objects rely on provider-side encryption; OAO does not add application-layer object encryption. The authenticated Files API can list and download regular files from the latest verified archive, but each download currently reads that compressed archive and does not support ranges or historical generations.
  • Routing price caps are not budgets. There is no project budget, reservation ledger, quota, or spend alerting, and no autonomous per-run model routing.
  • OpenAI preset text format is plain text only. The preset stores the Responses text.format choice, but JSON Schema authoring and structured output validation are not part of this control yet.
  • Daytona target selection is not an EU-residency guarantee. Strict EU controls and evidence are deferred beyond the MVP.
  • Daytona browser tools require Chromium in the sandbox image. The runtime starts Computer Use but does not install a browser into an arbitrary image.
  • Only selected file, shell, and browser tools are exposed. Daytona Git, LSP, code interpreter, recording, VNC, and preview APIs are outside the MVP.
  • Observed cost is not always final billed cost. The UI labels unavailable, provider-observed, and estimated data rather than presenting every value as authoritative billing.
  • Session debugging is intentionally detailed. The authorized management console exposes provider thinking, reasoning duration, and sandbox tool arguments/results. Credentials, authorization headers, provider reasoning signatures, and product-event payloads remain protected.
These constraints do not change the provider seams: model, sandbox, identity, artifact, telemetry, and runtime implementations remain replaceable adapters.