77 / PRODUCTION AI ARCHITECTURE / WHOLE PRODUCTION SYSTEM
77 / SYNTHESIS / 10 RUNTIME MODULES · PRODUCTION FABRIC · MODEL INFRASTRUCTURE · ADAPTIVE COMPLEXITY

PRODUCTION AI
ARCHITECTURE.

Production AI Architecture — синтез тем №01–76 в одну рабочую систему: как cognitive runtime, knowledge, tools, quality, security, model infrastructure, data lifecycle, queues/workflows и operations соединяются так, чтобы AI-продукт был не демо, а управляемой, измеримой, отказоустойчивой и адаптивной production-системой.

Ключевая идея всей серии: 76 изученных механизмов — не 76 микросервисов и не 76 обязательных шагов на каждый запрос. Production architecture состоит из 10 логических runtime-модулей, нескольких supporting infrastructure layers и набора механизмов, которые Executive Controller включает только тогда, когда они действительно нужны.
00. ARCHITECTURAL STATUS

DOCUMENTARY / DESIGN-TIME SYNTHESIS OF THE WHOLE SYSTEM

Canonical manifest фиксирует №77 как SYNTHESIS / DEFAULT N/A / SEPARATE COMPONENT N/A / Whole Production System. Это важно: №77 описывает, как собрать систему, но не добавляет одиннадцатый runtime module.
TYPESYNTHESISProduction architecture composition.
DEFAULTN/ANot a request-time toggle.
ENABLE WHENDESIGN / BUILD / REVIEWUsed to assemble a concrete product architecture.
SEPARATE COMPONENTN/ANo “ProductionArchitectureService”.
LIVES INWHOLE PRODUCTION SYSTEMSpans runtime and supporting infrastructure.
PRACTICAL VALUEINTEGRATIONTurns mechanism map into deployable system.
IMPLEMENT: AS AN ARCHITECTURE PROFILE
Минимум 80% ценности: one product task profile, 10 logical module interfaces, FAST/STANDARD/DEEP routing, typed contracts, durable state, controlled tools, evidence/RAG, verification, model gateway, observability/evals, production queues/workflows, permissions/security/governance, deployment topology, failure budgets and an explicit map showing which mechanisms are ON / CONDITIONAL / OFF for this product.
01A. ARCHITECTURE BOUNDARIES & OPERATIONS

EXPLICIT SYNTHESIS CONTRACT

A. BOUNDARY WITH NEIGHBORS

№41 Cognitive Architecture synthesizes the active cognitive runtime and Executive Controller around R01–R10. №77 is broader: it wraps that runtime with production controls, data/execution infrastructure, model infrastructure, security, governance, deployment and operations. №46 Observability, №47 Evals, №48–53 controls/security, №55–76 infrastructure each own their mechanisms; №77 composes rather than redefines them. №95 Master Map will later summarize the entire 01–95 knowledge map, including methodologies and metrics; №77 specifically answers “как выглядит production AI system”.

B. PREREQUISITES / CROSS-REFERENCES

Prerequisites: practically all №01–76, with especially strong dependencies on №41 Cognitive Architecture, №45 Verification, №46 Observability, №47 Evals, №48–53 controls/security, №55–69 data/execution/reliability infrastructure, №65 Gateway, №70 Serving and №76 Governance. Forward: №84–94 metrics measure whether the production system creates value; №95 maps the whole discipline.

C. CONTROL / DATA / RUNTIME / OFFLINE

CONTROL PLANE: policies, model/tool registry, prompts/skills/configs, routing rules, quotas, governance, deployment config. DATA PLANE: user inputs, retrieved evidence, artifacts, state, events, tool results, model traffic. RUNTIME: R01–R10 executing adaptive tasks. OFFLINE: evals, optimization, learning, ingestion, consolidation, indexing, incident analysis and deployment validation.

D. FAILURE & OPERATIONS CONTRACT

Architecture must define: request/run identity; durable vs ephemeral state; retries/idempotency; deadline/cancellation propagation; backpressure; failover; model/tool timeouts; verification gates; security/governance blocks; human escalation; observability; deployment rollback; recovery objectives and what happens when each dependency is unavailable.

E. WHAT THIS TOPIC DOES NOT OWN

№77 не вводит новые reasoning algorithms, storage engines, brokers, model servers or governance rules. Она владеет COMPOSITION: WHO CALLS WHOM, WHAT IS STATEFUL, WHAT IS CONDITIONAL, WHERE TRUST BOUNDARIES ARE, HOW FAILURE PROPAGATES, AND HOW THE WHOLE SYSTEM IS DEPLOYED AND OPERATED.

01. THE SYSTEM IN ONE PICTURE

USER EXPERIENCE → COGNITIVE RUNTIME → PRODUCTION FABRIC → MODEL / DATA INFRASTRUCTURE

┌────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                  CHANNEL / PRODUCT LAYER                                            │
│   Web / App / API / Slack / Email / Voice / Browser UI / Scheduled Events                         │
└──────────────────────────────────────────────────────┬─────────────────────────────────────────────┘
                                                       │
                                                       ▼
┌────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                           R01 EXECUTIVE CONTROLLER / ORCHESTRATOR                                   │
│   task contract · mode FAST/STANDARD/DEEP · budgets · routing · workflow ownership                 │
└──────────────┬──────────────────────────────────────────────────────────────────────┬──────────────┘
               │                                                                      │
               ▼                                                                      ▼
┌─────────────────────────────────────────┐                           ┌────────────────────────────────┐
│            COGNITIVE RUNTIME            │                           │       CONTROL / QUALITY         │
│ R02 Task Formulator                     │                           │ policies / permissions          │
│ R03 Decomposer / Planner                │                           │ verification / HITL             │
│ R04 Context Manager                     │                           │ observability / evals            │
│ R05 Working Memory + State              │                           │ governance / budgets             │
│ R06 Knowledge / Research Engine         │                           └────────────────────────────────┘
│ R07 Tool / Action Engine                │
│ R08 Quality Engine                      │
│ R09 Model Router                        │
│ R10 Learning Engine                     │
└──────────────┬──────────────────────────┘
               │
               ▼
┌────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                      PRODUCTION FABRIC                                             │
│ contracts · events · queues/workers · scheduler · broker · artifact store · provenance            │
│ cache · retries/circuit breakers · quotas · durable workflows · distributed reliability            │
└───────────────────────────────┬──────────────────────────────────┬─────────────────────────────────┘
                                │                                  │
                    ┌───────────▼───────────┐          ┌───────────▼────────────────┐
                    │  KNOWLEDGE / DATA     │          │     MODEL INFRASTRUCTURE    │
                    │ connectors / ingestion│          │ model gateway / serving     │
                    │ parsing / vector DB   │          │ hosted / self-hosted        │
                    │ graph / artifacts     │          │ quantization / multimodal   │
                    └───────────────────────┘          └────────────────────────────┘
                                │                                  │
                                └───────────────┬──────────────────┘
                                                ▼
┌────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                         CROSS-CUTTING SECURITY & GOVERNANCE                                        │
│ secrets · least privilege · injection defense · sandbox · data classification · retention         │
│ residency · deletion · tenant isolation                                                            │
└────────────────────────────────────────────────────────────────────────────────────────────────────┘
Production architecture is layered logically, but deployment can begin as one application + PostgreSQL + object storage + model API. Logical boundaries do not imply microservices.
02. 10 RUNTIME MODULES

THIS IS THE STABLE COGNITIVE SKELETON

R01

Executive Controller

Owns task run, complexity mode, orchestration, budgets, stop/escalation decisions.

R02

Task Formulator

Turns raw request into explicit objective, constraints, success criteria and ambiguity.

R03

Decomposer / Planner

Breaks difficult work into dependent steps and replans when evidence changes.

R04

Context Manager

Builds bounded task context from instructions, state, evidence and media.

R05

Working Memory + State

Owns active process state, intermediate artifacts, checkpoints and blackboard semantics.

R06

Knowledge / Research

Retrieval, RAG, external evidence, research hops, provenance-aware knowledge access.

R07

Tool / Action Engine

Typed tools, connectors, code/sandbox, browser/computer use, external actions.

R08

Quality Engine

Verification, deterministic checks, critics/judges when warranted, HITL boundaries.

R09

Model Router

Selects eligible model/deployment by policy, capability, quality, cost, latency and availability.

R10

Learning Engine

Feedback, lessons, memory consolidation, cases, prompt/skill/eval optimization offline.

These are logical responsibilities. A small system can implement R01–R10 as Python modules inside one service; split only when scaling, security or lifecycle requires it.
03. ADAPTIVE COMPLEXITY

FAST / STANDARD / DEEP — CENTRAL ANTI-OVERENGINEERING MECHANISM

FAST

Minimal sufficient path

Single-pass or near-single-pass. Minimal context. No multi-agent. No tree search. Tools/RAG only if obviously required. Cheap model where sufficient.

STANDARD

Normal production work

Decompose as needed, retrieve evidence, use tools, maintain working state, verify material outputs and permit bounded replan.

DEEP

Expensive deliberate path

Multiple candidates, critics, reasoning search, stronger models, simulation/formal solvers and human gate only when task risk/uncertainty/complexity justify it.

The architecture is not “better” when DEEP is used more often. It is better when the controller chooses the cheapest mode that reliably meets the task's success criteria.
04. COMPLEXITY ROUTER

TRIGGERS, NOT VIBES

SignalFASTSTANDARDDEEP trigger
Task ambiguityLowResolvable through context/retrievalMaterial ambiguity + high cost of wrong assumption
Evidence needNone/simpleRAG/tool lookupMulti-hop/conflicting/high-stakes evidence
Action riskRead-onlyReversible writesMoney, external publish, destructive/security changes
UncertaintyLowVerifier can resolvePersistent disagreement / weak evidence / unknowns
Reasoning depthDirect transformPlan + few stepsSearch, solver, simulation or candidates demonstrably help
Model needCheap sufficientStandardStrong model escalation justified by evals
05. REQUEST LIFECYCLE

ONE RUN, MANY CONDITIONAL MECHANISMS

INGRESSAuth, tenant, request ID, channel, deadlines.
FORMULATEObjective, constraints, success contract.
MODEFAST / STANDARD / DEEP.
CONTEXTState + memory + evidence candidates.
PLAN / ACTTools/RAG/model only where needed.
VERIFYRisk-based acceptance/revision.
COMMITOutput/action/artifact.
LEARN / TRACEFeedback/eval/lesson candidates.
06. RUN CONTRACT

EVERY EXECUTION NEEDS A STABLE ENVELOPE

{
  "run_id": "RUN-...",
  "tenant_id": "T-...",
  "principal_id": "P-...",
  "task_type": "research_report",
  "objective": "...",
  "success_contract": {
    "required_output_schema": "report/v3",
    "evidence_required": true,
    "verification_level": "MATERIAL_CLAIMS"
  },
  "mode": "STANDARD",
  "deadline_at": "...",
  "budgets": {
    "model_cost": 1.50,
    "tool_calls": 20,
    "steps": 30
  },
  "policy_context": {
    "data_class": "INTERNAL",
    "purpose": "ANALYSIS"
  },
  "correlation_id": "..."
}
RUN OWNS

One causal execution

  • identity;
  • tenant/principal;
  • task contract;
  • deadline/cancellation;
  • adaptive mode;
  • budgets;
  • policy context;
  • trace root;
  • final status.
07. CONTROL PLANE

CHANGE SYSTEM BEHAVIOR WITHOUT HARD-CODING IT INTO EVERY PROMPT

REGISTRIES

Models / tools / agents

Capabilities, versions, health, permissions and deployment refs.

POLICIES

Safety / governance

What may run, where data may go, which actions require approval.

CONFIG

Prompts / skills / routing

Versioned behavior configuration separate from application code where practical.

BUDGETS

Cost / quotas / time

Per tenant, task, model, tool and environment limits.

Control plane changes are deployment changes. Version them, evaluate them and roll them back.
08. DATA PLANE

REFS MOVE; LARGE BLOBS STAY IN STORES

STATE

Small structured records

Task phase, IDs, decisions, status and metadata.

ARTIFACTS

Large durable bytes

Files, reports, media, screenshots, datasets and exports addressed by stable refs.

MESSAGES

Bounded envelopes

Queues/broker carry IDs, small payloads, causation and artifact refs.

EVIDENCE

Addressable sources

Source versions/selectors/provenance rather than copied uncontrolled text everywhere.

Passing 40 MB PDFs through queue messages, workflow state and model prompts is a data-plane anti-pattern. Persist once, pass stable references.
09. PRODUCTION FABRIC

THE NON-COGNITIVE INFRASTRUCTURE THAT MAKES COGNITION SURVIVE REAL TRAFFIC

CONTRACTS

Typed boundaries

Structured inputs/outputs/errors/versioning. Prevent “prompt prose” from becoming the only API contract.

EXECUTION

Queues / Scheduler / Broker

Durable work, time-based triggers and pub/sub transport without conflating them with workflow semantics.

STATE / ARTIFACT

Durable references

PostgreSQL/kv + Artifact Store + provenance/lineage.

RELIABILITY

Retry / fallback / idempotency

At-least-once assumptions, circuit breakers, DLQ, reconciliation, locking and consistency.

LIMITS

Rate / quotas / budgets

Protect external providers and internal capacity from runaway agent loops.

OBSERVABILITY

Trace / metrics

Run → spans → tool/model/workflow events without hidden CoT.

SECURITY

Identity / permissions

Least privilege, secrets, trust boundaries, sandbox and injection controls.

GOVERNANCE

Data lifecycle

Classification, purpose, retention, residency, provider eligibility and deletion.

10. KNOWLEDGE PLANE

INGEST ONCE, ADDRESS PRECISELY, RETRIEVE ADAPTIVELY

EXTERNAL SYSTEMS / FILES / WEB
          ↓
      №54 CONNECTORS
          ↓
   №55 INGESTION & SYNC
 backfill / incremental / reconcile
          ↓
 №56 PARSING / OCR / EXTRACTION
          ↓
      DOCUMENT IR
 pages / blocks / tables / figures
          ↓
 ┌────────┴───────────┐
 ↓                    ↓
№66 VECTOR INDEX      №67 GRAPH (only if justified)
 ↓                    ↓
 └────────┬───────────┘
          ↓
  R06 KNOWLEDGE ENGINE
  №08 RAG / №27 Agentic RAG
          ↓
 evidence refs + selectors
          ↓
    R04 CONTEXT MANAGER
          ↓
         MODEL

ALL DURABLE OBJECTS:
  artifact_ref
  source_version
  provenance
  tenant/access
  governance metadata
Vector DB, graph, OCR and RAG are not four separate “agents”. They are retrieval/data capabilities owned by R06 and supporting infrastructure.
11. ACTION PLANE

MODEL NEVER DIRECTLY OWNS AUTHORITY

MODEL / PLANNER

Proposes typed action with intent and arguments.

R07 HOST EXECUTOR

Validates schema, permissions, policy, idempotency, sandbox/browser constraints.

EXTERNAL EFFECT

Tool/API/code/browser action → typed result → verification.

This host/model authority separation is one of the strongest production invariants in the architecture.
12. QUALITY PLANE

QUALITY IS NOT ONE “CRITIC AGENT”

DETERMINISTIC

First

Schema validation, tests, calculations, constraints, source existence and tool return codes.

EVIDENCE

Grounding

Material claims trace to exact source/version/selector.

MODEL REVIEW

Conditional

Critic/judge/self-consistency only where deterministic checks cannot answer.

HUMAN

Risk gate

Approval/handoff for high-impact ambiguity or actions.

R08 combines mechanisms by cost/risk. Verification №45 checks one result; Evals №47 measure system behavior across task sets.
13. MODEL PLANE

APPLICATION TALKS TO A MODEL GATEWAY, NOT TO RANDOM PROVIDER SDKs

R01 / R02 / R03 / R04 / R06 / R08
                ↓
              R09
         MODEL ROUTER
                ↓
        №65 MODEL GATEWAY
 policy → capabilities → health → quality → cost/latency
                ↓
 ┌──────────────┼─────────────────┬──────────────────┐
 ↓              ↓                 ↓                  ↓
HOSTED A      HOSTED B        LOCAL MODEL       SPECIALIZED
                                            vision/realtime/etc.
                ↓
        №70 SERVING PROFILE
      batching / KV / capacity
                ↓
 optional:
   №71 self-hosting
   №72 quantization
   №73 multimodal
   №75 realtime
Model names are configuration. Application-level code should depend on capabilities and contracts, not hard-coded provider details.
14. STATE TOPOLOGY

DIFFERENT STATE NEEDS DIFFERENT LIFETIMES

State classExampleTypical homeLifetime
REQUEST CONTEXTCurrent prompt sliceProcess/model contextSeconds/minutes
WORKING STATEPlan, phase, pending toolPostgres/Redis/workflow stateRun lifetime
ARTIFACTPDF/report/image/code resultArtifact StoreDefined lifecycle
MEMORYVerified durable fact/preferenceMemory storeLong-lived but governed
KNOWLEDGEExternal documents/chunksSource store + indexSource lifecycle
TRACERun/span/eventsTelemetry backendOperations retention
EVAL DATARepresentative task/sampleEval repositoryVersioned offline lifecycle
State Management №10, Memory №07 and Artifact Store №60 are different responsibilities. Mixing them into one “memory database” causes lifecycle and consistency problems.
15. SYNCHRONOUS VS ASYNCHRONOUS

NOT EVERY AGENT STEP BELONGS IN THE REQUEST THREAD

SYNCHRONOUS

User is waiting

Short model calls, low-latency RAG, fast tools, verification and final response. Propagate deadline/cancellation.

ASYNCHRONOUS

Durable work

Long research, document ingestion, exports, bulk inference, scheduled jobs, consolidation, indexing, evals and retraining pipelines.

Queue is not a workflow engine. Scheduler is not a queue. Broker is not a workflow. Durable workflow composes time, waits, retries and checkpoints around business semantics.
16. DURABLE EXECUTION

LONG-RUNNING WORK MUST SURVIVE PROCESS DEATH

R01 starts workflow RUN-42
        ↓
checkpoint task contract
        ↓
enqueue research step
        ↓
worker executes
        ↓
persist result/artifact refs
        ↓
workflow waits for:
  tool
  timer
  human approval
  event
        ↓
process crashes
        ↓
new worker replays workflow state
        ↓
does NOT repeat already committed side effect
because:
  operation_id
  idempotency
  reconciliation
        ↓
resume from durable checkpoint
№68 durable execution and №69 distributed reliability turn a logical workflow into an operationally survivable process.
17. EVENT / MESSAGE SEMANTICS

EVERY ASYNC EDGE NEEDS IDENTITY + CAUSATION + IDEMPOTENCY

{
  "message_id":"MSG-...",
  "type":"research.step.requested",
  "schema_version":3,
  "tenant_id":"T-...",
  "run_id":"RUN-...",
  "correlation_id":"RUN-...",
  "causation_id":"EVT-...",
  "operation_id":"OP-...",
  "payload":{
    "task_ref":"state://...",
    "input_artifact_refs":["artifact://..."]
  },
  "deadline_at":"...",
  "created_at":"..."
}
ASSUME AT-LEAST-ONCE

Consumers must be idempotent

Duplicate delivery, worker crash after commit, replay and retry are normal distributed-system events. Business effect identity must survive them.

18. FAILURE DOMAINS

FAILURES SHOULD STOP LOCALLY, NOT CASCADE THROUGH THE WHOLE SYSTEM

MODEL PROVIDER

Unavailable/slow

Timeout → compatible fallback → degraded model → bounded failure.

TOOL

External API failure

Circuit breaker, retry policy, stale/read-only fallback where valid.

RETRIEVAL

Index unavailable

Use direct source/API or declare evidence unavailable; do not hallucinate.

QUEUE / WORKER

Backlog

Backpressure, queue age alerts, autoscale or reject low-priority work.

POLICY / SECURITY

Unknown/blocked

Fail closed on sensitive operations, not “best effort allow”.

ARTIFACT STORE

Durable output unavailable

Do not mark workflow complete if required artifact was not durably stored.

OBSERVABILITY

Telemetry degraded

Depending on risk, buffer/outbox traces or block high-governance flows if audit evidence is mandatory.

HUMAN GATE

No response

Deadline/SLA → expire/escalate, not keep invisible zombie work forever.

19. DEADLINES & CANCELLATION

USER CANCELLATION SHOULD PROPAGATE THROUGH MODEL, TOOL, QUEUE AND WORKFLOW WHERE SAFE

REQUEST DEADLINE
   ↓
R01 remaining_budget_ms
   ↓
RAG timeout
MODEL timeout
TOOL timeout
SUBTASK timeout
   ↓
cancel if no longer useful

BUT:

cancel local wait
  ≠
undo committed remote effect

for consequential action:
  cancel before commit → stop
  cancel after unknown commit → reconcile
  cancel after confirmed commit → compensate only if business operation supports it
20. BACKPRESSURE

AGENTIC SYSTEMS CAN CREATE THEIR OWN LOAD MULTIPLIER

FAN-OUT

One request → 20 subtasks

Planning/search/subagents can multiply provider and worker demand.

CONCURRENCY LIMIT

Bound fan-out

Per-run, tenant and global limits.

QUEUE AGE

Pressure signal

Escalating backlog should reduce optional deep work before hard overload.

DEGRADE MODE

FAST under pressure

Disable optional critics/search/candidates and serve simpler path when policy permits.

Adaptive complexity is also an operations tool: system can shed optional cognitive work before shedding requests.
21. SECURITY TRUST BOUNDARIES

CONTENT, AUTHORITY AND EXECUTION MUST NEVER COLLAPSE INTO ONE CHANNEL

TRUSTED:
  system policy
  host code
  authenticated principal
  approved tool contracts
  permission service
  secret vault

UNTRUSTED:
  user content
  web pages
  retrieved documents
  emails
  PDFs
  image text
  audio/video content
  tool-returned external text

UNTRUSTED CONTENT MAY:
  inform reasoning

UNTRUSTED CONTENT MAY NOT:
  grant itself permissions
  reveal secrets
  expand allowed domains/tools
  bypass approval
  execute arbitrary code
  change system policy
This authority separation must survive every modality and every connector—not only prompts typed by a user.
22. GOVERNANCE IN THE REQUEST PATH

DATA POLICY IS A ROUTING INPUT

INPUT DATATenant, purpose, classification.
MINIMIZESelect required fields/regions.
POLICYAllowed processor/provider/region?
ROUTEOnly eligible model/tool.
PROCESSBounded payload.
TRACEMetadata-first.
LIFECYCLERetention/deletion links.
23. OBSERVABILITY MODEL

TRACE THE EXECUTION, NOT PRIVATE CHAIN-OF-THOUGHT

RUN

Business task

Objective, mode, outcome, cost, latency and final verification.

TRACE / SPAN

Execution topology

Plan step, retrieval, tool, model, worker, workflow or verifier calls.

EVENT

State transition

Retry, fallback, approval, cancellation, queue delay, circuit breaker and policy block.

ARTIFACT / PROVENANCE

Evidence lineage

Stable refs link outputs to inputs and transformations independently from trace retention.

Observability tells what ran. Provenance tells what data/evidence came from where. Evals tell whether system behavior is good across a task distribution.
24. ONLINE vs OFFLINE LOOP

PRODUCTION SYSTEM HAS TWO LOOPS

ONLINE LOOP

Serve task

Understand → plan → retrieve/tool → model → verify → act/respond under request budgets.

OFFLINE LOOP

Improve system

Collect traces/feedback → cluster failures → update evals → test prompts/routing/skills/models/policies → canary → deploy.

ONLINE:
task → run → outcome → trace → feedback

OFFLINE:
traces + feedback
      ↓
failure clusters
      ↓
eval dataset
      ↓
candidate changes
  prompt
  skill
  router
  retrieval
  model
  policy
  tool
      ↓
ablation / eval
      ↓
promote only if uplift
      ↓
production canary
R10 Learning Engine is not “model retrains itself continuously”. Most useful learning is safer configuration/memory/case/eval optimization without weight updates.
25. DEPLOYMENT ≠ LOGICAL ARCHITECTURE

SAME LOGICAL SYSTEM CAN HAVE 3 VERY DIFFERENT PHYSICAL TOPOLOGIES

MONOLITH

Small product

One application contains R01–R10 modules; Postgres + object store + external model/tool APIs. Best default until scale proves otherwise.

MODULAR SERVICES

Growing system

Split ingestion, async workers, model gateway, browser sandbox or governance services where scaling/security/lifecycle differ.

DISTRIBUTED PLATFORM

Large enterprise

Multiple product runtimes share model gateway, knowledge platform, queues/workflows, policy, observability and governance.

A “microservice per topic” is explicitly wrong. Separate deployment only for a concrete operational reason.
26. RECOMMENDED MINIMAL TOPOLOGY

START HERE, NOT WITH KUBERNETES + 40 SERVICES

                    ┌──────────────────────────┐
                    │      WEB / API APP       │
                    └────────────┬─────────────┘
                                 ↓
┌────────────────────────────────────────────────────────────┐
│               AI APPLICATION / ORCHESTRATOR                │
│ R01–R10 as logical modules                                 │
│ contracts · policy hooks · routing · verification          │
└───────┬──────────────────┬───────────────────┬─────────────┘
        │                  │                   │
        ↓                  ↓                   ↓
┌─────────────┐    ┌────────────────┐   ┌──────────────────┐
│ POSTGRESQL  │    │ ARTIFACT STORE │   │ MODEL GATEWAY/API│
│ state       │    │ files/reports  │   │ hosted models    │
│ memory      │    │ media          │   │                  │
│ metadata    │    └────────────────┘   └──────────────────┘
│ provenance  │
└──────┬──────┘
       │
       ↓
┌────────────────┐
│ VECTOR INDEX   │  optional / conditional
└────────────────┘

OPTIONAL WHEN NEEDED:
  worker queue
  durable workflow
  scheduler
  browser sandbox
  self-hosted model
  graph DB
For many products this topology can serve real production at meaningful scale before service decomposition is justified.
27. STANDARD TOPOLOGY

WHEN ASYNC WORK, MULTIPLE PRODUCTS OR HEAVIER LOAD APPEAR

EDGE / API GATEWAY
      ↓
PRODUCT AI API
      ↓
R01 EXECUTIVE / WORKFLOW CLIENT
      ├────────────────────────────────────────────────────┐
      │                                                    │
      ▼                                                    ▼
SYNC RUNTIME                                        DURABLE WORKFLOW
R02–R09                                              №68
      │                                                    │
      ├── R06 → Knowledge API                              ├── Queue → Workers
      ├── R07 → Tool Gateway                              ├── Scheduler
      ├── R08 → Verification                              └── Human waits/events
      └── R09 → Model Gateway
                         ↓
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
       Hosted        Self-hosted     Specialized
       model          model pool      vision/voice

SHARED PRODUCTION FABRIC:
  Postgres
  Artifact Store
  Broker / Queue
  Observability
  Policy / Secrets
  Governance
  Provenance
28. SCALE-OUT CRITERIA

SPLIT COMPONENTS ONLY WHEN A REAL AXIS DEMANDS IT

AxisSignalTypical split
CPU / async loadIngestion/research blocks APIWorker pool + queue
GPU lifecycleModel serving scales independentlyModel serving pool
SecurityBrowser/code needs containmentDedicated sandbox runner
AvailabilityLong workflows must survive deploysDurable workflow service
Team ownershipShared model/knowledge platformStable internal service interfaces
Data boundaryRestricted tenant/regionSeparate storage/processing boundary
TrafficOne module saturates independentlyScale that module, not entire architecture
29. ENVIRONMENTS

DEV / STAGING / PROD MUST DIFFER IN DATA AND AUTHORITY, NOT JUST HOSTNAME

DEV

Fast iteration

Synthetic/sanitized data, mock tools, limited secrets, cheap models, local traces.

STAGING

Production-like

Same contracts/policies/deploy topology, test tenants, sandbox providers, failure injection and release candidate configs.

PROD

Real authority

Strict secrets, governance, quotas, approvals, monitored model/tool routes and rollback-ready versions.

Do not make staging capable of sending real customer emails/payments merely because it uses “the same credentials for convenience”.
30. RELEASE UNIT

AI SYSTEM VERSION = MORE THAN CODE COMMIT

CODE

Application/runtime

Git/container version.

PROMPTS / SKILLS

Behavior config

Versioned templates/procedures.

MODELS / ROUTING

Deployment config

Provider/model snapshots, thresholds, escalation rules.

DATA / INDEX

Knowledge version

Parser/index/embedding/source versions where material.

POLICY

Authority

Guardrail/governance/permission versions.

TOOL CONTRACTS

Action surface

Tool schema/provider adapter versions.

EVAL SUITE

Acceptance basis

Representative tasks used to approve release.

DEPLOY PROFILE

Whole composition

One release manifest references all of the above.

31. RELEASE MANIFEST

REPRODUCE WHAT “PRODUCTION” MEANT AT A GIVEN TIME

{
  "release_id":"AI-SYS-2026-08-31.4",
  "app_version":"git:abc123",
  "prompt_bundle":"prompt://v18",
  "skill_bundle":"skills://v7",
  "router_config":"router://v11",
  "model_profiles":["model://..."],
  "tool_contracts":"tools://v9",
  "policy_bundle":"policy://v12",
  "governance_bundle":"gov://v5",
  "knowledge_profile":"knowledge://v23",
  "eval_suite":"evalset://prod/v16",
  "deployment_profile":"deploy://standard/eu/v4",
  "approved_at":"..."
}
WHY

Debug regressions

When acceptance falls after release, you can identify whether change came from code, prompt, model route, retrieval/index, policy or provider configuration.

32. CI / EVAL / DEPLOY GATE

NO PROMPT OR MODEL CHANGE DIRECTLY TO 100% PROD

CHANGECode/prompt/model/router/index/policy.
STATICContracts/security/schema checks.
OFFLINE EVALRepresentative suites + failure clusters.
LOAD / CHAOSCapacity/failure tests where relevant.
STAGINGEnd-to-end scenarios.
CANARYSmall production traffic.
COMPAREQuality/cost/latency/safety.
PROMOTE / ROLLBACKEvidence-based.
33. SLOs

AI QUALITY SLO + SYSTEM SLO

AVAILABILITY

Can serve

Request/workflow completion availability by task tier.

LATENCY

p50 / p95 / p99

End-to-end, model, retrieval and tool latency.

QUALITY

Eval / verification pass

Representative acceptance by task segment.

COST

Cost / success

Not just token spend; include retries/tools/humans.

SAFETY

Policy violation

Unauthorized action/data-flow/injection escape rates.

DURABILITY

Lost work

Durable workflow/artifact/provenance failure rates.

FRESHNESS

Knowledge lag

Source update → index/search availability.

HUMAN LOAD

Escalation burden

Manual review rate and queue SLA.

Later metrics topics №84–94 formalize business/AI metrics. Here they become operational release and runtime constraints.
34. PRODUCT TASK PROFILE

REUSE THE ARCHITECTURE BY CONFIGURING IT, NOT COPYING 76 MECHANISMS BLINDLY

product_profile:
  name: "SMM Post Writer"

  task_types:
    - social_post
    - rewrite
    - source_summary

  default_mode: STANDARD

  enabled:
    rag: conditional
    web_research: conditional
    verification: on
    browser_use: off
    voice: off
    debate: off
    reasoning_search: off
    self_consistency: off

  model_policy:
    default_tier: cheap
    escalation: uncertainty_or_eval_failure

  knowledge:
    source_scope: client_workspace
    vector_search: conditional

  tools:
    allowed:
      - fetch_source
      - save_draft

  governance:
    data_class: INTERNAL

  acceptance:
    grammar_check: required
    source_grounding: required_if_factual
THIS IS THE REUSABLE SYSTEM

Core + profile

Do not fork the conceptual architecture for every product. Keep stable runtime/fabric interfaces and create a task/domain profile selecting mechanisms, policies, knowledge, tools, models, budgets and evals.

35. THREE REFERENCE PROFILES

SAME ARCHITECTURE, DIFFERENT ACTIVATION

CapabilitySimple WriterResearch AgentAction Agent
Default modeFAST/STANDARDSTANDARDSTANDARD
RAGConditionalONConditional
Multi-hop researchOFFConditionalOFF
ToolsFew read/writeSearch/read/codeStrong typed action set
VerificationGrammar/source checksEvidence/claim verificationPre/post action verification
HITLOptionalHigh-stakes onlyConsequential commits
Browser UseOFFOFF/rareConditional
Deep reasoningRareConditionalMostly planning exceptions
Async workflowUsually noLong jobsWhen waits/approvals exist
36. MECHANISM MAP → COMPONENT MAP

TOPICS ARE KNOWLEDGE; COMPONENTS ARE IMPLEMENTATION

01–12 FOUNDATIONS
MCP, Skills, Subagents, Routing, Orchestration, Planning, Memory, RAG, Context, State, Workflows, Tools → mostly R01–R07 interfaces and strategies.
13–40 COGNITION
Problem formulation, decomposition, search, critics, reflection, uncertainty, evidence-first, research, code, simulation, learning, fine-tuning, optimization → mechanisms conditionally hosted in R02/R03/R06/R08/R09/R10.
41 COGNITIVE SYNTHESIS
Defines R01–R10 runtime architecture and Executive Controller.
42–54 CONTROL / SECURITY
Events, A2A, Registry, Verification, Observability, Evals, Guardrails, HITL, Contracts, Permissions, Agent Security, Sandbox, Connectors.
55–69 DATA / EXECUTION
Ingestion, parsing, queues, scheduler, broker, artifacts, provenance, caching, resilience, quotas, model gateway, vector/graph, durable execution and distributed reliability.
70–76 MODEL / MODAL / GOV
Serving, self-hosting, quantization, multimodal, browser, realtime and governance.
77 PRODUCTION SYNTHESIS
Composes the above into a concrete deployable architecture without adding a new cognitive module.
37. ANTI-MONSTER RULE

DO NOT BUILD A 30-AGENT ORGANIZATION CHART

TOPIC = SERVICE
95 documents become 95 deployables.
MAP TOPICS INTO R01–R10 + FABRIC
EVERY TASK = MULTI-AGENT
Latency/cost/debug surface explodes.
SINGLE EXECUTOR FIRST
EVERY ANSWER = CRITIC/JUDGE
Expensive duplicated inference with little uplift.
RISK-BASED VERIFICATION
EVERY QUERY = TREE SEARCH
Inference multiplier without evidence of value.
TRIGGER + ABLATION DELTA
MEMORY = EVERYTHING FOREVER
Privacy/staleness/context pollution.
CURATED CONSOLIDATION
KAFKA + K8S ON DAY 1
Infrastructure complexity before product evidence.
POSTGRES + WORKER FIRST
MODEL AS AUTHORITY
Prompt injection can control tools/secrets.
HOST POLICY BOUNDARY
PRODUCTION WITHOUT EVALS
No way to know if changes improve system.
EVAL-DRIVEN RELEASES
38. 80/20 STACK

WHAT TO BUILD FIRST FOR A SERIOUS GENERAL AI APPLICATION

1

R01–R10 interfaces

Can live in one app. Clear ownership beats physical separation.

2

PostgreSQL

State, memory, metadata, policy refs, provenance and small workflow records.

3

Artifact Store

Durable files/outputs/media referenced everywhere else.

4

Model Gateway

One abstraction for models, policy, routing, timeouts and telemetry.

5

Tool contracts

Typed execution boundary with permissions and idempotency.

6

Observability + Evals

Cannot optimize or debug without them.

7

Verification

Deterministic checks first, model/human escalation second.

8

Security + Governance

Identity, secrets, injection boundaries, data lifecycle.

9

RAG if needed

Source store + parser + retrieval; vector DB only when workload benefits.

10

Queue/Worker if needed

Add for long/bulk work, not merely because system is “agentic”.

11

Durable Workflow if needed

Long waits/retries/human gates/checkpoints.

12

Advanced cognition last

Search/debate/multi-agent only with measured eval uplift.

39. MVP REPOSITORY

A CONCRETE PROJECT SHAPE

ai_system/
├── app/
│   ├── api/
│   └── channels/
├── runtime/
│   ├── executive.py          # R01
│   ├── task_formulator.py    # R02
│   ├── planner.py            # R03
│   ├── context.py            # R04
│   ├── state.py              # R05
│   ├── knowledge.py          # R06
│   ├── tools.py              # R07
│   ├── quality.py            # R08
│   ├── models.py             # R09
│   └── learning.py           # R10
├── contracts/
├── policies/
├── prompts/
├── skills/
├── tools/
├── knowledge/
│   ├── ingestion/
│   ├── parsing/
│   └── retrieval/
├── production/
│   ├── queue/
│   ├── workflow/
│   ├── artifacts/
│   ├── provenance/
│   ├── caching/
│   └── resilience/
├── model_infra/
├── security/
├── governance/
├── observability/
├── evals/
├── profiles/
│   └── product.yaml
└── deploy/
IMPORTANT

Folders are responsibilities, not mandatory services

At MVP all of this can run inside one process plus PostgreSQL/object storage. Preserve interfaces and ownership so components can split later without rewriting the mental model.

40. BUILD ORDER

FROM SIMPLE RELIABLE CORE TO ADAPTIVE SYSTEM

PhaseBuildDo not build yet
0 — BaselineTask contract, single model, typed output, traces, eval set.Agents/search graphs/memory.
1 — Reliable CoreR01–R05, Model Gateway, verification, tools, policy/security.Distributed platform.
2 — KnowledgeR06, ingestion/parsing/RAG if task requires external knowledge.GraphRAG unless evals justify.
3 — ActionsR07 permissions, idempotency, sandbox/HITL for real effects.Computer use unless API missing.
4 — AsyncQueue/workers/workflow when long tasks appear.Broker zoo.
5 — AdaptiveFAST/STANDARD/DEEP, escalation, advanced cognition selectively.Always-on debate/search.
6 — ScaleSplit services/failure domains based on telemetry.Premature microservices.
41. END-TO-END EXAMPLE: RESEARCH REPORT

HOW THE WHOLE SYSTEM ACTUALLY INTERACTS

USER:
  "Analyze X and produce sourced recommendation"
        ↓
INGRESS:
  auth / tenant / deadline
        ↓
R02:
  objective + required evidence + output contract
        ↓
R01:
  STANDARD mode
        ↓
R03:
  4 research questions
        ↓
R06:
  internal RAG
  + web/tool research if authorized
        ↓
№61:
  provenance for sources/evidence
        ↓
R05:
  working state tracks open questions
        ↓
R04:
  context contains only relevant evidence
        ↓
R09:
  standard model
        ↓
draft
        ↓
R08:
  deterministic citation resolution
  claim/evidence verification
        ↓
uncertain key claim?
  yes
    ↓
  R01 escalates only that subproblem:
    multi-hop research / stronger model
        ↓
final report
        ↓
№60:
  durable artifact
        ↓
№46:
  trace cost/latency/failures
        ↓
№47:
  task may become eval sample if governed
        ↓
R10:
  failure/feedback enters offline improvement loop

NOT USED:
  debate
  browser
  voice
  graph search
  self-hosting
unless a real trigger appears.
42. END-TO-END EXAMPLE: ACTION AGENT

HOW AUTHORITY CHANGES THE ARCHITECTURE

USER:
  "Book the approved appointment"
        ↓
R02:
  resolve exact target/date/location
        ↓
R07:
  prefer typed scheduling API
  browser №74 only if API unavailable
        ↓
PERMISSIONS:
  can this principal create booking?
        ↓
R03:
  plan read availability → propose choice → commit
        ↓
READ-ONLY TOOL:
  fetch slots
        ↓
R08:
  verify chosen slot matches constraints
        ↓
CONSEQUENTIAL OPERATION:
  exact operation contract
  operation_id
        ↓
if approval required:
  №49 HITL
        ↓
R07 executes ONCE
        ↓
unknown outcome?
  reconcile before retry
        ↓
read-back confirms booking ID
        ↓
R08 PASS
        ↓
respond

SECURITY INVARIANT:
  tool/page content cannot expand authority.

RELIABILITY INVARIANT:
  retry cannot create duplicate booking.
43. SYSTEM VALIDATION HARNESS

THE ARCHITECTURE SHOULD BE TESTABLE AS A WHOLE

STATIC

Architecture checks

Contracts, refs, topic→module ownership, enabled mechanisms, policy completeness and version consistency.

E2E

Task scenarios

Representative product tasks from ingress to verified output/action.

ABLATION

Does mechanism help?

Disable RAG/critic/search/strong model and measure delta before accepting complexity.

FAILURE

Chaos scenarios

Provider outage, queue duplication, stale data, tool timeout, policy block, worker crash and human timeout.

SECURITY

Adversarial

Prompt injection, exfiltration attempts, confused-deputy and cross-tenant access.

GOVERNANCE

Lifecycle

Retention, deletion propagation, backup restore and provider routing.

LOAD

Capacity

Backpressure, queue age, model saturation and latency tail behavior.

RELEASE

Canary comparison

Quality, cost, latency, safety and human escalation vs current production baseline.

This is how a second coding agent can validate the final implementation: treat the architecture documents as an executable specification and map every invariant to tests.
44. CRITICAL INVARIANTS

IF THESE HOLD, THE SYSTEM IS FUNDAMENTALLY HEALTHY

I01

Every run has identity

run_id, tenant, principal, deadline and trace root.

I02

Every side effect has identity

operation_id/idempotency + reconciliation.

I03

Model has no implicit authority

Host validates policy/permissions/tool contract.

I04

Durable outputs are actually durable

Artifact/store commit precedes READY status.

I05

Evidence is addressable

Source version + selector + provenance for material claims.

I06

Complexity is conditional

Expensive mechanisms need triggers and eval uplift.

I07

Retries are bounded

No infinite agent/tool/workflow loops.

I08

Data policy travels with data

Tenant/classification/purpose/retention survive derivatives.

I09

Every production change is measurable

Versioned release + eval/canary/rollback path.

45. ARCHITECTURE REVIEW CHECKLIST

QUESTIONS BEFORE CALLING IT “PRODUCTION”

AreaQuestion
Task contractCan we define success/failure without reading the model's mind?
ModeCan easy requests avoid expensive mechanisms?
StateWhat survives process crash? What is ephemeral?
ToolsWho authorizes side effects? Are retries idempotent?
KnowledgeCan every cited fact resolve to exact source/version?
ModelsCan provider/model change without changing product code?
SecurityCan untrusted content ever expand authority?
GovernanceCan we find and delete every governed derivative?
ReliabilityWhat happens when each dependency times out or duplicates work?
ObservabilityCan we explain which components ran and why without storing hidden CoT?
EvalsCan we prove a new mechanism/model actually improves representative tasks?
DeploymentCan we roll back code + prompt + model route + policy config coherently?
46. PRACTICAL DECISION

WHAT SHOULD №77 BECOME IN A REAL PROJECT?

QuestionAnswer
Стоит ли реализовывать?Да — как architecture/profile/specification. Не как отдельный runtime service.
Separate Component?N/A. №77 spans the whole production system.
Минимум 80% ценности?10 logical modules, adaptive modes, production fabric, typed contracts, model gateway, durable state/artifacts, quality/security/governance, eval-driven release and one concrete product profile.
Когда overkill?Пытаться физически реализовать каждый механизм серии до появления соответствующего trigger.
Trigger?Whenever turning conceptual AI capability into a deployable product or validating an existing architecture.
Как измерить uplift?System-level: verified task success, latency, cost/success, availability, policy violations, escalation burden, recovery time and eval delta.
Можно ли rule/tool/code заменить отдельный LLM-agent?В большинстве production-control задач — да. Contracts, policy, routing constraints, retries, queues, governance and verification should be deterministic wherever possible.
47. DESIGN RULES

THE PRODUCTION RULEBOOK

RULE 01

10 logical modules, not 76 services

Topics are mechanisms. Deployments are chosen by operational needs.

RULE 02

FAST by default

Spend cognition only when risk/uncertainty/complexity demands it.

RULE 03

Typed boundaries everywhere

Model/tool/worker/workflow/action contracts are machine-validatable.

RULE 04

Refs over blobs

Artifact/source/state refs move through the system; durable bytes stay in stores.

RULE 05

Authority stays in host

Model proposes; deterministic code/policy authorizes execution.

RULE 06

At-least-once by assumption

Idempotency/reconciliation are baseline, not later patches.

RULE 07

Verification is risk-based

Deterministic first; critic/human only when warranted.

RULE 08

Every change runs through evals

No architectural complexity without demonstrated delta.

RULE 09

Core + product profile

Reuse architecture by configuration rather than copying a monolith blindly.

48. FINAL MASTER MAP

FROM USER INTENT TO A RELIABLE PRODUCTION OUTCOME

┌──────────────────────────────────────────────────────────────┐
│                         PRODUCT                              │
│ Web · API · App · Email · Slack · Voice · Scheduled Events  │
└──────────────────────────────┬───────────────────────────────┘
                               ↓
                        AUTH / TENANT
                               ↓
                     RUN / TASK CONTRACT
                               ↓
                ┌──────────────────────────┐
                │ R01 EXECUTIVE CONTROLLER │
                └────────────┬─────────────┘
                             ↓
                    SELECT MINIMAL MODE
                             ↓
             ┌───────────────┼───────────────┐
             ↓               ↓               ↓
           FAST           STANDARD          DEEP
             └───────────────┼───────────────┘
                             ↓
        ┌─────────────────────────────────────────┐
        │ R02 TASK FORMULATOR                     │
        │ R03 DECOMPOSER / PLANNER                │
        │ R04 CONTEXT MANAGER                     │
        │ R05 WORKING MEMORY + STATE              │
        │ R06 KNOWLEDGE / RESEARCH ENGINE         │
        │ R07 TOOL / ACTION ENGINE                │
        │ R08 QUALITY ENGINE                      │
        │ R09 MODEL ROUTER                        │
        │ R10 LEARNING ENGINE                     │
        └────────────────────┬────────────────────┘
                             ↓
          CONDITIONAL COGNITIVE MECHANISMS

 RAG · multi-hop · agentic retrieval · code · solver · simulation
 self-consistency · critic/judge · reflection · reasoning search
 model escalation · subagents · human gate

        ONLY WHEN TRIGGER + EVAL VALUE JUSTIFY THEM
                             ↓
──────────────────────── PRODUCTION FABRIC ─────────────────────

CONTRACTS
  typed input/output/errors/version

EXECUTION
  events
  queues/workers
  scheduler
  broker
  durable workflows

STATE
  PostgreSQL / state store
  artifact store
  provenance
  caches

RELIABILITY
  timeout
  bounded retry
  fallback
  circuit breaker
  idempotency
  reconciliation
  DLQ
  backpressure

LIMITS
  quotas
  cost
  concurrency
  deadlines

OBSERVABILITY
  run → trace → span → event
  metrics
  no hidden CoT

QUALITY
  deterministic checks
  evidence
  verification
  evals
  HITL

SECURITY
  principal
  scopes
  secret vault
  injection defense
  sandbox
  least privilege

GOVERNANCE
  classification
  purpose
  retention
  residency
  provider eligibility
  deletion
                             ↓
──────────────────────── KNOWLEDGE / DATA ──────────────────────

connectors
  ↓
ingestion / sync
  ↓
parsing / OCR / Document IR
  ↓
source versions / artifacts
  ↓
vector search / HNSW / embeddings
  + graph only if justified
  ↓
retrieval
  ↓
evidence refs + provenance
                             ↓
──────────────────────── MODEL INFRASTRUCTURE ──────────────────

R09 ROUTER
  ↓
№65 MODEL GATEWAY
  policy
  capability
  health
  quality
  cost
  latency
  ↓
hosted models
self-hosted models
quantized models
multimodal models
realtime models
  ↓
№70 SERVING
  batching
  KV
  capacity
  latency
                             ↓
──────────────────────── ACTION SURFACE ────────────────────────

typed API tools FIRST

if needed:
  code sandbox
  browser/computer use
  voice/realtime
                             ↓
for consequential action:
  precondition
  permission
  approval
  operation_id
  execute
  verify
  reconcile
                             ↓
──────────────────────── VERIFIED OUTCOME ──────────────────────

answer
artifact
business side effect
workflow result
                             ↓
trace + provenance + feedback
                             ↓
──────────────────────── OFFLINE LEARNING ──────────────────────

production traces
  ↓
failure clusters
  ↓
eval datasets
  ↓
candidate improvements:
  prompt
  skill
  context
  retrieval
  routing
  model
  policy
  tool
  memory
  fine-tuning only if necessary
  ↓
ablation + eval
  ↓
staging
  ↓
canary
  ↓
promote / rollback

══════════════════════════════════════════════════════════════════

THE SERIES DOES NOT DESCRIBE
A GIANT AGENT THAT DOES EVERYTHING.

IT DESCRIBES
A CONTROLLED SYSTEM
THAT CAN DO MORE
ONLY WHEN IT NEEDS TO.

PRODUCTION AI ARCHITECTURE =
  SIMPLE DEFAULT PATH
+ EXPLICIT CONTRACTS
+ ADAPTIVE COGNITION
+ DURABLE STATE
+ CONTROLLED ACTIONS
+ EVIDENCE
+ VERIFICATION
+ MODEL ABSTRACTION
+ RELIABILITY
+ SECURITY
+ GOVERNANCE
+ OBSERVABILITY
+ EVAL-DRIVEN CHANGE

AND THE MOST IMPORTANT RULE:

DO NOT ASK
"HOW MANY OF THE 76 MECHANISMS
CAN WE PUT INTO THIS PRODUCT?"

ASK:

"WHAT IS THE SMALLEST
ARCHITECTURE THAT PASSES
OUR REAL TASK EVALS,
SURVIVES REAL FAILURES,
RESPECTS REAL AUTHORITY,
AND CAN GROW
WITHOUT BEING REWRITTEN?"

ECC RETROFIT / PRACTICAL HARNESS INTEGRATION

A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №77 Production AI Architecture.

B–E. Existing boundary and placement. The existing conceptual boundary, class SYNTHESIS, default N/A and owner Whole Production System remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.

F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.

I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.

K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.