> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oao.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# MVP limitations

> Know which workflows are implemented now and which remain explicit extension points.

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](/integrations/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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.