Candidate standards

These are proposals that EOS could turn into standards. They are intentionally not phrased as adopted policy. Each candidate records the source basis, the reason it may generalise, and the decision still required.

Evidence scale

• Strong convergence: both OpenAI and Anthropic recommend or practise the same underlying approach.
• Supported: one vendor gives direct guidance and other sources are compatible with it.
• Case-study hypothesis: a reported practice is promising but strongly dependent on context.

Repository knowledge

CS-01: Root agent instructions are a map

Candidate: Keep root agent instructions short and limited to repository orientation, universal constraints, canonical commands, mandatory workflow triggers, and links to deeper sources of truth. Do not use the root file as the repository encyclopedia.

Evidence: Strong convergence. OpenAI reports that a monolithic AGENTS.md crowded out useful context, became stale, and resisted mechanical validation; its replacement is a roughly 100-line table of contents. Anthropic recommends root-wide facts in root instructions and subsystem guidance in nested files or path-scoped rules. Anthropic separately recommends keeping CLAUDE.md below roughly 200 lines and moving specialised procedures to skills.

Decision needed: Define a target rather than a universal hard line count, and specify the required root sections for EOS-managed repositories.

CS-02: Repository knowledge is indexed, versioned, and owned

Candidate: Knowledge required to build, validate, operate, or review the software must be available in the repository, linked from an index, assigned an owner, and reviewed with code changes. External narrative may remain elsewhere, but execution-critical rules cannot exist only in chat or a knowledge base.

Evidence: Strong convergence. OpenAI treats structured repository docs as the system of record and mechanically checks structure, cross-links, and freshness. Anthropic recommends committed root and per-directory instructions owned by the relevant teams and reviewed through pull requests.

OpenAI’s concrete system separates architecture, indexed design documents, product specifications, generated references, active/completed plans, technical debt, discipline guides, and quality grades, with recurring doc-gardening to repair stale content.

Decision needed: Define document ownership metadata and the boundary between Notion narrative and repository-operational knowledge.

CS-03: Complex work has a durable execution plan

Candidate: Cross-package or long-running work must write a plan with scope, sequence, progress, decisions, validation, and remaining work to a durable file.

Evidence: Strong convergence. Anthropic recommends saving cross-package plans because files survive compaction. OpenAI versions execution plans, decision logs, completed plans, and technical debt so agents do not depend on external or conversational state.

Decision needed: Define when a plan becomes mandatory and its storage and retention conventions.

Skills and reusable workflows

CS-04: Skills have narrow routing contracts

Candidate: Every skill description states the triggering task or repository state, exclusions or negative examples, expected output, and success criteria. The main skill remains a concise workflow and routes to optional references, examples, assets, and scripts.

Evidence: Strong convergence. Both vendors describe metadata as the routing boundary and full skill content as progressively disclosed. OpenAI recommends explicit negative cases and reports recovered routing accuracy after adding them. Anthropic recommends the key use case first because descriptions may be truncated and suggests keeping SKILL.md below 500 lines.

Decision needed: Define required frontmatter, maximum sizes, and a common cross-client description format. Also define long-session behaviour: Claude’s documented compaction budgets can truncate or remove invoked skills.

CS-05: Mandatory workflows are explicitly triggered

Candidate: If a repository requires a workflow for completion, root or path-scoped instructions express it as a short conditional rule and explicitly invoke the skill or deterministic command. Automatic skill selection alone is not enforcement.

Evidence: Strong convergence. OpenAI’s Agents SDK repositories put if/then skill triggers near the top of AGENTS.md; OpenAI’s production guidance says to name the skill explicitly when determinism matters. Anthropic provides manual-only invocation controls for side-effecting tasks and permissions for specific skills.

Decision needed: Decide which workflows are required by change class and whether CI independently enforces completion.

CS-06: Model judgement and deterministic mechanics are separated

Candidate: Scripts perform repeated mechanics in a fixed order and expose clear CLI contracts; the model interprets evidence, compares intended and actual behaviour, makes contextual judgements, and produces explanations.

Evidence: Strong convergence. OpenAI explicitly uses this split in verification, example execution, release review, and handoff workflows. Anthropic recommends offloading preprocessing to hooks and executable support files rather than repeatedly spending model context on mechanics.

Decision needed: Define the CLI contract expected of skill scripts, including stdout, stderr, exit codes, artifact paths, and idempotency.

CS-07: Skills are evaluated on routing and outcomes separately

Candidate: A shared skill must have fresh-context positive, negative, and ambiguous routing cases plus output assertions. Benchmark with and without the skill and record pass rate, duration, and tokens.

Evidence: Strong convergence. Anthropic explicitly separates activation from performance and documents isolated A/B evaluation artifacts. OpenAI reports targeted routing regressions that were not visible without evals and provides outcome improvements from production skill use.

Decision needed: Select an evaluation format and minimum release gate for EOS-distributed skills.

CS-08: Start local, package after stabilisation

Candidate: Develop a workflow beside the code, stabilise its instructions and scripts through local use, then package it for cross-repository distribution or CI. Shared packages are namespaced, versioned, documented, and owned.

Evidence: Strong convergence. Anthropic recommends standalone configuration for project work and experimentation, then plugins for sharing and versioned updates. OpenAI recommends debugging workflows locally before running the same skill in GitHub Actions and keeping the workflow stable across local and hosted execution.

Decision needed: Define the promotion criteria and supported EOS packaging and distribution mechanism.

Verification, hooks, and CI

CS-09: Verification is conditional but completion-blocking

Candidate: Repositories define change classes and the ordered verification required for each. Expensive stacks do not run for unrelated changes, but an applicable stack must pass before work is reported complete.

Evidence: Supported by OpenAI’s Agents SDK practice and compatible with Anthropic’s recommendation to give precise verification targets and test incrementally. OpenAI’s code verification skills condition on runtime, test, example, or build behaviour changes while allowing docs-only work to remain lightweight.

The same case study separately validates examples from source intent and logs, and installs published JavaScript packages into Node, Bun, Deno, Cloudflare Workers, and a Vite application. Passing repository tests alone is not always the required evidence.

Decision needed: Define EOS change classes and how affected-workspace calculation interacts with repository-specific commands.

CS-10: Hooks implement narrow event-driven guarantees

Candidate: Use command hooks for deterministic lifecycle actions such as formatting, protected-file checks, concise output filtering, environment reload, audit, and client-specific context restoration. Match the narrowest event and arguments, parse structured input, provide actionable failure output, and set timeouts.

Evidence: Strong convergence in current product documentation. Both clients load lifecycle hooks, run matching command hooks concurrently, and cannot undo completed actions from post-use hooks. OpenAI explicitly describes PreToolUse as a guardrail with incomplete tool-path coverage; Anthropic warns that argument filters are best-effort. Both therefore require native rules or permissions—not hook interception alone—for hard allow/deny boundaries.

Decision needed: Choose the cross-client abstraction: native hooks where available, wrapper scripts, or EOS CLI lifecycle events.

CS-11: Generated artifacts have an explicit source of truth

Candidate: A generated file declares its editable source and regeneration command. Skills audit or change the source and regenerate; they do not patch generated output directly.

Evidence: Strong convergence. OpenAI’s docs-sync uses source docstrings and comments rather than generated reference output. OpenAI’s repository model separates generated docs; Anthropic recommends excluding generated files from routine reads.

Decision needed: Define headers, validation, and CI checks for generated artifacts.

CS-12: Public CI agent workflows treat triggers as a security boundary

Candidate: Write-capable agent jobs on public input require trusted triggers or explicit approval, sanitised prompt inputs, least-privileged execution, protected credentials, and ordering that keeps the agent step after safer deterministic preparation.

Evidence: Explicit OpenAI recommendation. The article identifies trigger design, input handling, and runtime privileges—not the skill alone—as the main risk around public untrusted input.

Decision needed: Produce a threat model and approved GitHub Actions patterns before enabling write-capable public workflows.

Context, execution, and security

CS-13: Scope context and filesystem access to the task

Candidate: Start work at the smallest useful subtree, expand access only for known dependencies, exclude generated and vendored content, and prefer symbol intelligence over broad scans. Broad changes identify affected packages and validation boundaries before editing.

Evidence: Strong convergence. Anthropic gives concrete launch-directory, exclusion, sparse-worktree, additional-directory, and language-server patterns. OpenAI emphasises scarce context, progressive disclosure, predictable structure, and inspectable dependencies.

Decision needed: Define client-neutral expected outcomes and separate them from Claude-specific settings.

CS-14: Network and secret access is layered and task-specific

Candidate: Skills and shell do not imply open networking. Organisation policy defines the maximum destinations; each task receives a smaller allowlist. Authenticated calls inject credentials at the network boundary without exposing raw values to the model, and remote tool output is treated as untrusted.

Evidence: Explicit OpenAI recommendation. The shell/skills article calls skills plus open networking a high-risk exfiltration path and recommends organisation and request-level allowlists plus domain-bound secrets. Anthropic’s hook and permission material reinforces separate tool boundaries.

Decision needed: Select a runtime capable of enforcing destination-bound credentials and document exceptions for local development.

CS-15: Each tool owns a real security boundary

Candidate: Tool schemas, authentication, filesystem access, network access, approval policy, and audit are reviewed per tool. A sandbox around one shell or file tool must never be assumed to constrain MCP or other external tools.

Evidence: Strong convergence. OpenAI’s agent-loop description explicitly limits the Codex shell sandbox to that tool. Anthropic distinguishes permission rules from hook filters and notes that arbitrary subprocesses may bypass built-in read controls.

Decision needed: Define EOS tool onboarding and security-review requirements.

CS-16: Security policy uses native authority controls

Candidate: Hard command, filesystem, network, credential, and external-tool boundaries must use the applicable sandbox, permission, execution-rule, managed policy, or tool-authorization layer. Hooks may add contextual denial, audit, or remediation but cannot be the only enforcement mechanism.

Evidence: Strong convergence. OpenAI documents incomplete PreToolUse interception and experimental command-prefix rules whose most restrictive match wins. Anthropic recommends permissions instead of best-effort hook argument filters and notes that built-in read denial does not constrain arbitrary subprocesses.

Decision needed: Define the EOS authority model and the minimum native controls required for each supported client and tool class.

CS-17: Portable workflows have client adapters

Candidate: Cross-client capabilities share one source for procedural intent, references, and deterministic scripts, while discovery locations, invocation metadata, manifests, hooks, permissions, and trust configuration remain explicit client adapters. Generated mirrors must have a declared source and drift check.

Evidence: Supported by the shared Agent Skills format and materially different OpenAI and Anthropic configuration. Codex uses .agents/skills, agents/openai.yaml, .codex-plugin/plugin.json, trusted .codex layers, and command-only hooks today. Claude uses .claude/skills, Claude-specific skill frontmatter, .claude-plugin/plugin.json, different settings inheritance, and a broader hook-handler set.

For shared root instructions, a verified CLAUDE.md symlink to AGENTS.md is the lowest-drift adapter where all supported environments preserve it; a small routing file is the fallback.

Decision needed: Select the canonical source layout and generation or packaging strategy for EOS-managed dual-client capabilities.

CS-18: Configuration discovery is tested from real launch locations

Candidate: Repositories supporting agents test instruction, skill, settings, hook, rule, and plugin discovery from the repo root and representative subdirectories, trusted and untrusted checkouts, and worktrees where applicable.

Evidence: Strong convergence. Both clients use working-directory-sensitive discovery, but with different traversal and inheritance. Anthropic separately documents launch-directory, worktree, and non-inherited settings behavior; OpenAI loads nested project config toward the working directory and ignores project .codex layers until trust is granted.

Decision needed: Define a portable discovery conformance test and the supported launch locations for EOS repositories.

Harness architecture and operation

CS-19: Agent state uses thread, turn, and typed item lifecycles

Candidate: An interactive harness models durable threads, bounded turns, and typed items for messages, tool calls, results, approvals, diffs, and artifacts. Items have started, streaming, and terminal states; the server may pause a turn for approval.

Evidence: Supported by OpenAI’s App Server architecture and consistent with the agent-loop event model. This is a concrete design rather than cross-vendor consensus.

The concrete lifecycle is item/started, optional typed delta events, and item/completed, bounded by turn events; approval is a server-initiated request that can pause the turn.

Decision needed: Validate whether EOS needs a runtime protocol or only adapters to existing harnesses.

CS-20: Long-running work has server-side durable state

Candidate: A browser or terminal client is not the source of truth for a long-running task. The runtime persists state and events, permits reconnect and catch-up, and separates client release cadence from runtime evolution with version or capability negotiation.

Evidence: Supported by OpenAI’s App Server practice. OpenAI’s hosted shell guidance also recommends container reuse, stateful continuation, durable artifacts, and compaction from the start.

Decision needed: Determine persistence, retention, reconnect, cancellation, and compatibility requirements for any EOS runtime.

CS-21: Prompt assembly is stable and cache-aware

Candidate: Keep stable instructions, examples, images, and tool definitions in a deterministic prefix; append changing environment or permission state rather than rewriting earlier context where the runtime permits it; enumerate tools deterministically.

Evidence: Explicit OpenAI implementation guidance. Exact-prefix prompt caching can be invalidated by tool order, model changes, sandbox or approval changes, and working-directory changes.

Decision needed: This applies only to harnesses EOS owns. Define cache-hit telemetry before making it a standard.

CS-22: Compaction preserves durable task state

Candidate: Compact proactively and preserve objective, decisions, plan, changed artifacts, evidence, validation, blockers, and remaining work. The repository and artifact store—not the verbatim transcript—must be sufficient to resume.

Evidence: Strong convergence. Both vendors recommend compaction for long runs; Anthropic supports custom preservation instructions and restoring context through SessionStart with the compact matcher, while OpenAI documents PreCompact/PostCompact, automatic and explicit compaction, and durable filesystem handoffs.

Decision needed: Define a client-neutral compact-state schema and test it with resume evaluations.

Architecture and maintenance

CS-23: Enforce invariants centrally and allow implementation autonomy

Candidate: Mechanical checks enforce dependency direction, boundary parsing, structured logging, schema and type naming, reliability constraints, and other high-value invariants. Their error messages explain remediation. Within those boundaries, agents may choose implementation details.

Evidence: Case-study hypothesis from OpenAI’s agent-first product, supported by both vendors’ preference for deterministic enforcement. The exact rigid layer model is contextual and should not be copied wholesale.

Decision needed: Identify Tillo-wide invariants versus repository-family invariants and measure false-positive cost.

CS-24: Agent throughput requires continuous garbage collection

Candidate: Repositories maintain a small set of mechanical “golden principles,” scan for deviations on a cadence, track quality by domain, and open small focused cleanup changes before drift compounds.

Evidence: Case-study hypothesis. OpenAI reports replacing a weekly manual cleanup day with recurring scans, quality grades, and targeted refactoring PRs. Anthropic recommends telemetry to identify unused skills and ongoing review of instructions after model changes.

OpenAI’s concrete principles include centralising invariants in shared utilities and validating boundaries or using typed SDKs instead of building on guessed data shapes.

Decision needed: Define the initial quality dimensions, review ownership, and which cleanup changes may be automated.

CS-25: Human review focuses on consequential choice

Candidate: Automated review handles repeatable correctness checks, common regressions, and missing tests. Human decision-makers remain required for competing API or architecture designs, product behaviour and compatibility, naming and migration choices, rollout policy, and cross-team sequencing.

Evidence: Explicit OpenAI observed practice and recommendation from the Agents SDK case study. It should be calibrated to risk and maturity rather than treated as permission to remove review gates universally.

OpenAI’s separate harness case study uses minimal blocking gates only because its correction throughput and recovery loop make waiting unusually expensive; the article explicitly calls the same policy irresponsible in a low-throughput environment.

Decision needed: Define risk classes and the evidence required before a repository can reduce human review for any class.

CS-26: Autonomous changes produce reviewable evidence

Candidate: Before an agent can drive a change end to end, the repository must support baseline validation, reproducible failure evidence, implementation, fix evidence, review-feedback handling, build-failure recovery, and explicit human escalation for judgement calls. Evidence is stored as structured events or artifacts rather than only a final message.

Evidence: Case-study hypothesis from OpenAI’s harness engineering work, reinforced by the Agents SDK example and integration-test workflows. The exact use of browser recordings is contextual; the requirement for reproducible before/after evidence generalises.

Decision needed: Define evidence types by change risk, storage and retention, and which decisions always require human approval.