mirror of
https://github.com/boshu2/agentops.git
synced 2026-09-14 15:08:13 +08:00
Bo
7a765cde19
Executes docs/plans/2026-08-07-agentops-operations-layer-alignment.md: AgentOps is the operations layer for agentic engineering; the federated integration graph is the topology, the semantic work-and-proof protocol is the contract, and RPI is the standard one-experiment traversal. Retires the ao flywheel command family and all knowledge-flywheel product state, tombstones the seven-move operating-loop workflow, narrows ao init and the .agents state writers to declared destinations, renames the core architecture page to rpi-traversal.md with a compatibility redirect, aligns AGENTS.md, 25 skills, public and package copy, regenerates every owned projection, and strengthens the conformance gates with planted-negative proofs. Both the alignment subject and the follow-up gate-bookkeeping commit carry fresh author-distinct validation PASS verdicts with empty not_checked scope. Test-Removal-Reason: dead knowledge-flywheel and session-store surfaces were deleted with their tests (operations-layer alignment)
1.2 KiB
1.2 KiB
title, description, permalink, last_reviewed
| title | description | permalink | last_reviewed |
|---|---|---|---|
| AgentOps as a Trust Boundary | How AgentOps identifies and independently judges one bounded agent-created change. | /trust-factory | 2026-07-14 |
AgentOps as a Trust Boundary
Generation is stochastic. AgentOps adds a small, inspectable boundary between an agent's claim and a caller's decision to rely on it.
The boundary has four facts:
- the requested behavior and acceptance are explicit;
- the exact subject is identified by content, not by a mutable branch name;
- a distinct fresh context judges that subject against the acceptance;
- the result identifies checked and unchecked scope and can be persisted as a
standalone content-addressed
verdict.v2when a consumer requires it.
This is evidence, not permission to ship. AgentOps does not own Git, CI, tracking, retries, queues, release, or recovery. The consumer system decides what to do after PASS, FAIL, or NOT_PROVEN.
Optional Premortem, Council, and multi-model strategies can strengthen the judgment selected by the caller. Optional Learn analysis can study collections of past verdicts later. Neither changes the core lifecycle.
See PRODUCT.md and the RPI traversal.