// plain-English reference
Clear definitions for the systems that connect, observe, govern, test, and improve production agents. Punk's product terms are included alongside the broader category language.
An agent system needs more than a model. Production infrastructure must decide how requests move, what actions are allowed, what evidence is trustworthy, and whether experience can safely improve future execution.
// core layers
An infrastructure layer that observes agent execution, applies policy, identifies repeated work, tests alternative paths, and routes eligible future requests through verified execution with live fallback and a reason for the decision. Read the category definition.
A traffic layer between applications and model providers. It commonly centralizes compatible APIs, credentials, provider selection, limits, retries, cost controls, and sometimes caching.
The practice and tooling used to inspect agent requests, responses, tool calls, traces, latency, cost, evaluations, errors, and outcomes. Observability explains execution; it does not inherently change the next route.
Rules and controls that define which models, data, tools, users, and actions are allowed. Governance can include identity, policy evaluation, approvals, blocks, audit records, and risk classification.
// proof and rollout
Running a candidate path against recorded historical inputs while suppressing side effects, then comparing its outputs and behavior with an accepted reference. Replay tests known traffic; it cannot prove every future case.
Running a candidate silently beside the current live path on fresh traffic. The live result still serves while the system collects comparison evidence and suppresses candidate side effects.
The defined evidence and policy requirements a candidate must pass before it can become eligible to serve. In plain English: verification before activation.
A deliberately limited production release to a small, identified slice of eligible traffic. A canary measures real behavior while containing the effect of an unexpected mismatch.
Returning an ineligible, uncertain, or failed optimized request to the configured live model provider. Fallback behavior must be designed alongside the organization's policy and availability needs.
A machine- and human-readable reason attached to a response that states which execution path was chosen and why. It makes routing inspectable instead of invisible.
// reuse and economics
A stored result reused when the relevant request and safety scope match exactly.
A stored result considered for requests that are similar in meaning, subject to thresholds, freshness, policy, and tenant or subject boundaries.
Reuse of a prior tool result when its inputs, authorization scope, freshness rules, and side-effect posture allow it. Writes should not be treated like ordinary read caches.
A tested, declarative execution path derived from repeated behavior. Punk interprets these workflows as data; it does not generate and evaluate executable code.
An estimate of what a candidate route might have saved while observation or shadow mode still served the live path. Ghost savings are forecasts, not realized savings.
Measured cost avoided after an eligible route actually serves production traffic, net of the costs included by the stated methodology.
// Punk technical terms
| Technical term | Plain-English meaning | Why it matters |
|---|---|---|
| Trace ledger | Complete append-only execution history | Derived patterns and routes can be rebuilt from their source evidence. |
| Artifact | Tested reusable workflow | Repeated agent work can become a declarative path instead of generated code. |
| Artifact promotion | Make a verified workflow eligible | Reuse requires replay and shadow evidence plus policy approval. |
| Side-effect level | Risk level for an action | Reading data and making an irreversible external change should not receive the same controls. |
| Semantic web runtime | Structured, machine-usable web state | Agents can act on page meaning and available interactions rather than only brittle visual coordinates. |
| Variables from messages | Consistent inputs derived from a conversation | Routing, synthesis, replay, and serving must evaluate the same request representation. |
// important distinctions
A model can return a valid completion while the user's job still fails. Meaningful evaluation often needs application outcomes, human feedback, or domain-specific checks.
A replayable record can support internal review and compliance work. It is not, by itself, a certification or a guarantee that an organization's controls meet a regulation.
A compatible model endpoint can capture supported request traffic. Complete agent context may also require tool, identity, approval, browser, and outcome integration.
Replay and shadow tests provide bounded evidence for defined traffic and acceptance rules. They should not be presented as proof of all future correctness.
Follow a request from live observation through candidate testing, eligibility, fallback, and route explanation.