Skip to Content
WhitepaperPrimitives: Agents, Ingredients, Recipes

Primitives: Agents, Ingredients, Recipes

Chapter 5 Primitives: Agents, Ingredients, Recipes This chapter defines the agents that every subsequent chapter references. In the Scrypted Network, every component is an agent—a versioned, billable, self-monitoring entity with a stable interface contract and an on-chain identity. Agents come in two structural forms: node agents (atomic capabilities, informally called ingredients) and graph agents (composed workflows, informally called recipes). Both are implementations of the AVB (Autonomous Virtual Being) standard. Everything else—orchestration, billing, verification, identity—operates on these agents. 5.1 Ingredients as node agents An ingredient is the atomic unit of capability in the Scrypted Network. Each ingredient has a single, declared role: generate an image, classify text, extract JSON, invoke an external API, crop a video, fetch credentials. An ingredient is identified by a namespaced string (ingredient_id_string), registered in a PostgreSQL-backed registry, and carries: • A human-readable name and description. • A set of I/O parameters (IngredientIOParameter): typed inputs and outputs that define the contract other components program against. • One or more versions (IngredientVersion), each binding either to a runtime implementation (code bundle, handler path) for atomic ingredients, or to a plan definition (recipe JSON) for composed ingredients. • Optional spec metadata (JSONB): arbitrary structured data for tooling, discovery, and registry surfaces. On-chain identity. Every agent registered in the Scrypted Network maps to an ERC-8004 contract address on Ethereum and Solana. The ERC-8004 architecture provides one master identity contract per chain (ERC-721 agent records with endpoint metadata, capability declarations, and x402 support flags), alongside potentially many reputation provider contracts (structured feedback per agent, filterable by reviewer) and verification provider contracts (attestations corresponding to the Class A/B/C verification spectrum in Chapter 12). The on-chain address is the canonical identifier; the namespaced slug is internal shorthand. As ERC-8004 addresses become primary, namespace governance concerns diminish—the contract address is the namespace. The ingredient contract is deliberately heterogeneous. An ingredient can be: 21

Kind Example Deterministic code SHA-256 content hasher, aspect-ratio converter Network call to a generative model FAL Nano-Banana text-to-image, AWS Bedrock LLM External API bridge Morpheus API Gateway, ElevenLabs Dialogue Agentic reasoner Delula prompt analyzer (LLM + structured output) Orchestration primitive Video orchestrator v1 (manages sub-jobs internally) Moderation filter Bedrock Guardrails, content moderation router Utility Wait timer, error propagator, token counter This uniformity is the foundation for composition: the orchestration engine (Chapter 6) does not distinguish between a five-millisecond hash function and a twenty-minute video render. Both are ingredients; both have cost models; both are versioned. As of the current production registry, 118 ingredient interfaces are registered, spanning generation, moderation, analysis, orchestration, converters, and external bridges (see Appendix B for the full inventory). 5.1.1 On-chain identity via ERC-8004 Every agent — whether ingredient or recipe — has a registered ERC-8004 contract address on Ethereum and/or Solana. There is one master identity contract per chain; agents are entries within it. Each identity entry carries: • Service endpoints: web URLs, A2A Agent Cards, MCP manifests, OASF descriptors. • x402 support flags: whether the agent accepts HTTP 402 payment challenges and which settlement tokens it supports. • Capability metadata: declared I/O types, supported modalities, and version pointers. • Reputation pointers: references to one or more reputation provider contracts that hold structured feedback for this agent. • Verification pointers: references to one or more verification provider contracts that hold attestation records for this agent. The identity contract is singular per chain, but the reputation and verification provider contracts are many: any party may deploy a provider contract and attach attestations to an agent’s identity. This separation is load-bearing — it prevents any single reputation or verification authority from becoming a gatekeeper. Different verification provider contracts correspond to different verification classes on the trust spectrum (Chapter 12, §12.1): a Class A (CRPC) provider contract records commit–reveal pairwise comparison attestations; a Class B (reputation-only) provider records structured client feedback and routing reliability signals; a Class C (EigenAI / ZK) provider records TEE attestation quotes, zkML proofs, or optimistic re-execution results. An agent can be attested by multiple verification providers simultaneously, accumulating evidence across the spectrum. 5.2 Recipes as graph agents A recipe is a directed acyclic graph (DAG) of steps, where each step invokes an ingredient. Recipes are defined in JSON: • Metadata: recipe id, version, name, author, tags. 22

• Input schema: typed parameters the caller provides (intent text, orientation, quality level, etc.). • Steps: each step declares a step_id, a uses field (ingredient id), an inputs mapping that may reference prior steps’ outputs via template expressions ({steps.<id>.outputs.*}), optional depends_on edges, execution hints (async, timeout_ms, retry_policy), and an optional condition — an expression evaluated against prior steps’ outputs; if the condition evaluates to false, the step is skipped (marked complete with no execution). • Output mapping: which step outputs become the recipe’s outputs. The condition field transforms recipes from linear data-flow pipelines into programmable decision graphs. Steps can gate on safety signals, budget thresholds, quality scores, or any boolean expression over the DAG’s accumulated state. A recipe is loaded into the database as an IngredientVersion with version_type = recipe and its JSON stored in plan_definition. This means a recipe, once registered, is an ingredient — callable by other recipes as a single step. This recursive property is the mechanism behind what the vision document calls “infinite abstraction”: a ten-step video generation recipe becomes a one-step primitive inside a batch-production recipe. The current repository contains 35 recipe JSON files with well-formed metadata, covering text generation, image generation, video generation and orchestration, audio generation, moderation assessment, embeddings, forecasting, and multi-modal analysis. 5.3 Horizontal and vertical composition Agents cooperate through two composition patterns: 5.3.1 Horizontal composition (workflow-level) Steps in a recipe execute as nodes in the DAG managed by the orchestration engine. Data flows through declared edges. Each step is a first-class unit for logging, metrics, billing attribution, and (future) reputation events. Steps may execute in parallel when their dependency edges permit. Interface contract: step_id, uses (ingredient id), typed inputs mapping, optional condition, optional async flag, timeout_ms, depends_on list. 5.3.2 Vertical composition (embedding-level) One ingredient calls another in-process — for example, a generator ingredient importing a credential-fetch ingredient directly. Vertical calls are synchronous and fast; long-running work must use horizontal async paths. Cost attribution: The parent step owns the cost. Vertical calls are rolled up into the parent’s estimates unless explicitly split by policy. 5.3.3 When to use which Horizontal Vertical Reuse across recipes; swap implementations; need per-step retries, timeouts, billing Helper is an implementation detail of a single agent Different teams own different steps Latency-sensitive, deterministic glue ERC-8004 identity / billing events per capability Cost is negligible, bundled with parent 23

This distinction matters for the wrapper threat model (Chapter 11, §11.7): horizontal composition makes wrapper depth visible in the recipe graph; vertical composition hides it. Depth disclosure is a network-level policy question. 5.3.4 Conditional branching: programmable decision graphs Recipe DAGs are not limited to data flow—they support conditional execution at any node. A step may declare a condition expression that references prior steps’ outputs: { “step_id”: “fail_if_blocked”, “condition”: “{steps.router.outputs.should_block} == true”, “uses”: “scrypted:util:error”, “inputs”: {“code”: “BLOCKED”, “message”: ”…”} } The orchestration engine evaluates the condition before dispatching the step. If false, the step is marked as completed-with-skip ({“skipped”: true}), and downstream dependents proceed as if the step succeeded. Supported operators include ==, !=, >, <, >=, <=, with template variable resolution against the accumulated step results. Worked example: content moderation pipeline. The production moderation-text-assessment recipe demonstrates conditional short-circuiting:

  1. guardrail_check — fast Bedrock Guardrails safety scan (sync).
  2. router_decision — evaluates guardrail results; outputs should_block.
  3. fail_if_security_violation — conditional: fires only if should_block == true, terminating the recipe with an error.
  4. rule_assessment — LLM-based detailed evaluation (reached only if guardrail passed).
  5. parse_assessment — structured output parsing. This pattern generalizes to any decision point in a workflow: Condition pattern Use case should_block == true Safety gate: block before expensive generation cost_estimate > 1.0 Budget gate: route to cheaper provider quality_score < 0.7 Quality gate: retry with different model provider_available == false Availability gate: fallback routing complexity == “high” Complexity routing: use more capable model Conditional branching makes recipe DAGs programmable decision graphs—agents that route execution based on intermediate results, not just flow data between steps. Combined with the recursive property (graph agents compose into other graph agents), this creates agents that make economic and quality decisions at every node. Richer condition logic (AND/OR composition, nested conditions) is a committed engineering direction that will further extend this capability beyond conventional workflow engines. 24

Horizontal (recipe DAG) A B C D Vertical (in-process) Parent ingredient Child helper call sync Figure 5.1: Composition patterns. Horizontal: steps are first-class DAG nodes (billing, retries, discovery). Vertical: nested calls roll up to the parent step. 5.4 Versioning, deprecation, and the registry Each ingredient supports multiple concurrent versions. A version record (IngredientVersion) carries: • version_number (monotonically increasing integer). • version_type: atomic (backed by a runtime implementation) or recipe (backed by a plan definition). • is_default_version: exactly one version per ingredient is the default, resolved when a caller does not specify a version. • deprecated_at: nullable timestamp; when set, the version is still callable but marked for removal. • Cost model (IngredientCostModel): one of fixed, rated, or post_execution — detailed in Chapter 7. • Fault tolerance configuration: optional retry, circuit-breaker, timeout, and fallback policies (JSONB), applied by the orchestration engine. • Tags: many-to-many labels for categorization and discovery. Deprecation lifecycle: Setting deprecated_at signals to callers and tooling that the version should be migrated away from. The network does not hard-delete deprecated versions immediately; in-flight jobs referencing them complete normally. This aligns with the reallocate / fork / deprecate mutation patterns described in the agentic agenda. 5.5 Usage classes The 118 registered ingredients fall into broad classes, useful for organizing the catalog, estimating capacity, and mapping to whitepaper chapters: 25

Class Examples Generation (image) Nano-Banana, Seedream 4, FLUX 2 Pro, AWS Nova Canvas, Grok Imagine Generation (video) Sora 2, Kling, Hailuo, Google Veo 3/3.1, OVI, AWS Nova Reel Generation (text) AWS Bedrock LLM (Nova Pro, Llama, Qwen), Venice Uncensored Generation (audio) ElevenLabs Dialogue, MMAudio, Kling Video-to-Audio Analysis / vision Vision Analysis Structured, AWS Nova Vision, video motion estimator Moderation / safety Bedrock Guardrails, content moderation router/orchestrator, cache store Orchestration / media Video orchestrator v1/v2, media stitch, media FFmpeg, duration planner Converters / utilities Aspect-ratio converter, token utilities, JSON extractor, error utility External API bridges Morpheus API Gateway, FAL adapter Embeddings BGE-M3 text embeddings Forecast Time series forecast The full machine-regenerable catalog is in Appendix B. The classes above are heuristic groupings; a more formal taxonomy (e.g., aligned to ERC-8004 capability URIs) is an open design question for the registry chapter (Chapter 11). 26

Source: transcribed from the compiled Scrypted Network Design whitepaper PDF for web reading. Layout, figures, and pagination may differ from the PDF.

Last updated on
The Problem ExplainedPart 1