Skip to content

PRD.md

Latest commit

 

History

History
89 lines (70 loc) · 4.11 KB

PRD.md

File metadata and controls

89 lines (70 loc) · 4.11 KB
Raw

Agent Runtime Services PRD

PRD.md is the fixed formal L0 projection of the product narrative in README.md and README.zh-CN.md for Agent Runtime Services. Together they define product intent before architecture contracts, capability descriptors, provider ports, storage adapters, RPC methods, CLI commands, package metadata, or tests are changed.

It is intentionally thin. It does not replace the public product narrative, and it is not a runtime manual, implementation plan, capability-specific PRD, or repository-maintenance record.

L0 Problem

Domain agents and build agents repeatedly need model access, provider selection, secret lookup, artifact and record persistence, memory storage, vector retrieval, resource readiness, and local RPC exposure. If each consuming agent owns those support planes directly, projects duplicate provider and storage code, blur runtime support with agent decision authority, and drift at the contracts shared across agents.

Agent Runtime Services exists to provide that project-neutral runtime service plane while preserving the boundary that consuming agents own domain judgment, approval, tool choice, session mutation, user-facing behavior, and coordinated action.

P0 Scope

P0 is a local-first Runtime Services package with two reusable layers:

  • Runtime Core: provider-neutral model calls, artifact persistence, JSON record metadata including optional single-record atomic compare-and-set, memory storage, vector search, resource status, provider config, secret resolution, capability envelopes, and operator smoke checks.
  • Agent Services: composed, agent-facing services built on Runtime Core for reusable memory, context, retrieval, or delivery contracts.

The public surface includes the TypeScript library entrypoint createRuntimeServices(config), localhost JSON-RPC at /rpc, CLI/operator commands, CapabilityRegistry, explicit storage isolation keys, Runtime Services envelopes, and package publication assets.

The memory substrate is the first Agent Service in P0. Its downstream contract is documented in architecture/memory-substrate-prd.md, but that file does not own root product intent.

Non-Goals

  • Do not make Runtime Services a domain agent, build agent, execution agent, task coordinator, approval engine, chat assistant, or organizational-memory product.
  • Do not let a capability-specific document, architecture note, test, or repository-maintenance file redefine root L0 product intent.
  • Do not encode a single consuming project, channel, execution endpoint, or provider as the public product boundary.
  • Do not expose plaintext secrets, share credentials across projects by default, or expose remote MCP tools before scoped authorization exists.
  • Do not treat passing tests, smoke output, or package dry-run as operator acceptance, publication approval, or production readiness.

Downstream Chain

Formal development flows from the co-equal public narrative and PRD L0 assets into runtime-service implementation and validation assets:

README.md / README.zh-CN.md / PRD.md
  -> architecture/README.md + architecture/storage-retrieval-design.md
  -> CapabilityRegistry + architecture capability contracts
  -> provider ports + storage/service/RPC contracts
  -> TypeScript runtime, CLI, adapters and package metadata
  -> contract, acceptance, publication and smoke tests

Capability-specific documents such as architecture/memory-substrate-prd.md are downstream L1/L2 contract assets. They can explain why a capability belongs in P0 and how it is proven, but they must stay aligned with this PRD and the public product narrative.

Owner Boundary

Human owner or architect owns L0-L2 product intent, service-layer boundaries, authority rules, capability contract freeze, package publication, credential operations, remote exposure, and real provider smoke decisions.

Agents and engineers own L3-L4 implementation and validation under that frozen boundary. Return to README / PRD or architecture review when a change would alter product scope, service-layer classification, capability authority, storage isolation, remote exposure, package contents, or acceptance meaning.