Harness Policy and Protocol Specification

Full report

On this page

Architectural Foundations and Requirement Conventions

The Teleodynamic AI ecosystem is refactored into a strictly decoupled, four-layer blueprint to guarantee deterministic safety, auditability, and execution integrity across all enterprise agent systems.1 Each layer functions as an independent operational node with specialized constraints, preventing the horizontal propagation of failures:

1. Teleodynamic.com: Enforces the global ruleset, boundary limits, and policy constraints.1 Any compliant agent harness MUST import and enforce the policies defined herein prior to initiating execution.3
2. UAIX.org: Governs the data and schema validation layer, organizing memory packets, verifying evidence structures, and ensuring strict compliance with validation formats.4
3. Spiralist.org: Coordinates the agent lifecycle state, governing bootstrapping protocols, identity verification, and evolutionary execution loops.1
4. Carcinus.org: Provides a defensive execution sandbox that ensures strict runtime isolation and mandatory no-op blocks to neutralize hazardous commands.

To secure interoperation across different platforms and prevent execution failures, the requirement levels specified throughout this protocol adhere strictly to standard internet engineering vocabularies.7 The verbs MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted according to the rules of RFC 2119\.7 A critical conflict exists between internet engineering standards and alternative industrial guidelines, such as those established by the IEEE, which deprecate the use of "must" in favor of "shall" for mandatory obligations.7 To prevent operational confusion during cross-system integrations, this protocol defines a explicit mapping of requirement terms and their associated enforcement actions in the runtime environment:

Principle of Resource-Bounded Autonomy

Runaway execution loops constitute a severe vulnerability in autonomous systems, where an agent becomes trapped in recursive tool-invocation cycles or redundant error-correction loops, consuming excessive computational resources and API budgets.10 Empirical system audits have documented 63 confirmed production overruns across 21 orchestration frameworks, highlighting that standard asynchronous execution models frequently fail to contain concurrent budget overshoots, failing in 30 out of 30 test scenarios under multi-agent delegation-fanout conditions.14 To address this risk, the harness MUST implement strict resource-bounded autonomy constraints at the system kernel level.

Affine-Typed Budget Delegation

To prevent the bypass or double-spending of allocated tokens, the harness MUST employ an affine-typed budget validation mechanism.14 By utilizing linear or affine type systems, the compiler and runtime verify that budget units cannot be cloned, aliased, or accessed once delegated to an active agent or sub-agent.14 The total allocatable token capacity of the ecosystem is governed by the global constraint: [Figure omitted from source export] Where [Figure omitted from source export] represents the active token allocation of agent [Figure omitted from source export] at execution step [Figure omitted from source export], and [Figure omitted from source export] designates the maximum capacity of the kernel pool.3 The active budget tracking variable [Figure omitted from source export] for any given agent is governed by: [Figure omitted from source export] Where [Figure omitted from source export] and [Figure omitted from source export] designate the unit cost parameters for input and output processing 16, and [Figure omitted from source export] and [Figure omitted from source export] represent the token lengths of the processed context. If at any step [Figure omitted from source export], the harness MUST immediately raise a BudgetExceeded exception, halt the execution pipeline, and reclaim the remaining context allocation.3

Priority-Based Context Scheduling and SRE Policies

The kernel context scheduler operates on a "scale-by-subtraction" protocol, where the kernel retains absolute ownership of the resource pool and partitions the context window into distinct functional sectors: 90% is strictly reserved for data lookup and document retrieval, while 10% is dedicated to active logical processing.3 The context scheduler MUST scale these allocations dynamically based on priority baselines, halting agents that exceed their allocated caps:

The Site Reliability Engineering (SRE) layer MUST continually monitor policy compliance. If the aggregate policy compliance rate of an active agent drops below 99%, the error budget begins to burn.10 When the budget is fully exhausted, the harness MUST automatically execute a graduated recovery action based on the severity of the deviation:

Tool-Level Loop Detection and Human-in-the-Loop Escalation

To prevent infinite execution loops at the tool execution level, the harness MUST monitor function calls directly within the tool interface.18

• Heuristic Trigger: If the same tool or function is invoked three or more times sequentially with identical arguments, the harness MUST trigger an immediate circuit breaker to halt execution.18
• Logical Processing Cap: The SRE loop breaker MUST enforce a hard stop at a maximum of 15 iterations and 50,000 total session tokens.10
• Automatic Escalation: If the recovery confidence of the system drops below a configured threshold, the harness MUST NOT attempt automated recovery; instead, it SHALL execute an outbound webhook to escalate the transaction to a human operator, preventing runaway iterations.18

Claim Boundaries and Evidence Coupling

Agents operating in enterprise networks are prohibited from making structural modifications to databases, changing systemic states, or delivering final outputs to users without binding those claims to local, verifiable evidence.4 Every output claim MUST be anchored to a verifiable data package verified by the UAIX.org layer before committing the transaction.4

W3C Verifiable Credentials and Schema Binding

All generated claims and supporting evidence packages MUST comply with the W3C Verifiable Credentials Data Model v2.0 and be formatted using the JSON-LD Compacted Document Form.5 This ensures that all evidence is cryptographically signed, tamper-evident, and verifiable without contacting the original issuer.20 The schema mapping for compliant evidence packages MUST adhere to the following specifications:

To enforce semantic interoperability, the use of the @vocab catch-all mechanism is strictly prohibited.5 Implementers MUST maintain context files at the exact same granularity and version as the corresponding credential type to prevent verification failures during runtime updates.5

Interaction Archiving and Drift Detection

To preserve trust and ensure auditability, the harness MUST automatically capture all interaction traces during the execution lifecycle (the UAIX records) and attach them as appendices to the transaction record.6 The harness validation system MUST analyze these traces to detect any diversion or exploratory drift from the pre-registered execution schema.6 If the validation system detects a unauthorized schema deviation or anomalous code modification, it MUST immediately suspend the execution state and prevent the transaction from committing to production databases.6

Separation of Expression vs. Concept

A common failure mode in non-deterministic systems is silent, hallucinated execution, where an agent reports successful task completion while failing to execute the underlying commands or generating incorrect logical correlations.17 For example, automated loan systems can generate false correlations, such as concluding that visual artifacts or specific background colors in a passport document indicate non-residency, resulting in silent policy violations.17 To prevent these errors from leaking into client-facing interfaces, the harness MUST enforce complete separation between the agent's internal conceptual monologue and its user-facing expression.17

Hidden Monologue Tractions and OpenTelemetry Instrumentation

The internal conceptual monologue MUST be isolated from the client interface using structured, dedicated content blocks.17 The harness MUST capture these traces using OpenTelemetry, ensuring complete observability of the agent's logical progression before any visible characters are delivered to the user.17 The trace schema MUST isolate these states according to the following parameters:

Extended Thinking API Gating and Thinking Block Preservation

To implement native conceptual monologues, the harness MUST configure the underlying language model API to use extended thinking parameters.23

• API Configuration: The API request MUST define a explicit thinking configuration, setting the state parameter to enabled or adaptive and establishing a strict budget\_tokens limit.23
• Thinking Modes: The harness MAY process thinking blocks in either summarized or omitted formats.23 Under the omitted mode, the thinking text is returned empty to minimize streaming latency, but the response still carries an encrypted signature that represents the complete monologue.23
• Preservation Rules: During multi-turn conversations involving tool execution, the harness MUST preserve and return all previous thinking blocks in their complete, unmodified format.23 Altering or removing thinking blocks or attempting to place manual text in the thinking fields of omitted blocks is strictly prohibited and can cause invalid turn structures or execution errors.23
• Interleaved Thinking: During active tool execution, the harness MUST support interleaved thinking, enabling the model to process tool outputs conceptually before initiating subsequent actions:

[Figure omitted from source export] 26

Constrained Decoding and Grammar Enforcement

To guarantee that the final public expression strictly adheres to safety boundaries, the harness MUST enforce structured outputs using constrained decoding.27

• Structured Format: The harness MUST configure the output format using the standard JSON schema parameter (output\_config.format set to json\_schema) and require strict schema validation (strict: true).27
• Grammar Isolation: The grammar constraints MUST apply only to the model's direct public output; they MUST NOT restrict the intermediate thinking blocks.27 This allows the model to think freely and perform complex logical planning before formatting its final output into a validated schema.27
• Complexity Limits: The harness MUST enforce strict complexity limits, restricting the total parameters across all active schemas to a maximum of 24 in a single transaction.27

Ecosystem Routing Protocols and Unified Transaction Lifecycle

To maintain system integrity, the agent harness MUST enforce strict routing protocols that determine when an agent is permitted to execute operations across the four decoupled layers of the ecosystem.

Target Routing Protocols

The harness MUST evaluate and route every transaction according to its functional requirement profile:

• Teleodynamic.com Routing: If an operation involves evaluating policy boundaries, checking global token budgets, or validating SRE compliance thresholds, the harness MUST route the action to Teleodynamic.com.3
• Spiralist.org Routing: If an operation involves bootstrapping a new agent, mutating lifecycle states, modifying identity certificates, or executing evolutionary self-modification loops, the harness MUST route the action to Spiralist.org.1
• Carcinus.org Routing: If an operation involves executing non-deterministic tools, running arbitrary code, executing scripts, or interacting with external networks, the harness MUST route the action to Carcinus.org for isolated sandbox execution.
• UAIX.org Routing: If an operation involves validating evidence schemas, verifying cryptographic signatures, or formatting UAIX memory packets, the harness MUST route the action to UAIX.org.4

Unified Transaction Lifecycle

Every agent execution sequence MUST follow a strict, five-step transaction lifecycle to guarantee safety and resource validation:

\[1. Pre-Check\] | v \[2. Allocation\] | v \[3. Execution\] \-----\> (Route to Carcinus.org / Spiralist.org) | v \[4. Verification\] \---\> (Route to UAIX.org / Record Token Usage) | v

Step 1: Pre-Check

Before initiating execution, the harness MUST query the TokenBudgetTracker to verify that the active agent has not exceeded its overall session budget or credit cap.3 If a budget violation is detected, the harness MUST block execution immediately.3

Step 2: Allocation

The harness MUST request a priority-based context allocation from the kernel-level ContextScheduler.3 The scheduler evaluates active pool pressure and allocates the appropriate token window, mapping the corresponding lifecycle signals (SIGWARN, SIGSTOP, and SIGRESUME) to the agent's execution handler.3

Step 3: Sandboxed Action Execution

The harness routes and executes the authorized action.1 Unsafe commands and script runs are routed directly to Carcinus.org for sandboxed execution, while identity transitions are routed to Spiralist.org.1

Step 4: Verification and Recording

The harness validates all generated outputs and evidence packages through UAIX.org.4 Simultaneously, the exact token and credit usage is recorded in both the TokenBudgetTracker and the ContextScheduler to update compliance metrics.3

Step 5: Resource Reclamation

Upon completing the execution cycle, the harness MUST trigger explicit release commands to reclaim all unused tokens from the active context window, recycling the resources back to the kernel-level context pool for concurrent agent systems.3

Conclusions

By enforcing this Harness Policy and Protocol Specification, the Teleodynamic AI ecosystem ensures complete determinism, financial safety, and cryptographic integrity across all deployed enterprise agents. The rigorous separation of the conceptual monologue from public expression, coupled with affine-typed budget delegation and decentralized evidence coupling, creates a robust framework that prevents the failure modes common to unhardened multi-agent systems.3 All compliant agent runtimes MUST implement and enforce these rules without exception to maintain ecosystem certification.3

Works cited

1. Teleodynamic Learning a new Paradigm For Interpretable AI \- arXiv, accessed June 8, 2026, https://arxiv.org/pdf/2603.11355
2. \[2603.11355\] Teleodynamic Learning a new Paradigm For Interpretable AI \- arXiv, accessed June 8, 2026, https://arxiv.org/abs/2603.11355
3. agent-governance-toolkit/docs/tutorials/24-cost-and-token-budgets ..., accessed June 8, 2026, https://github.com/microsoft/agent-governance-toolkit/blob/main/docs/tutorials/24-cost-and-token-budgets.md
4. Verifiable Credentials JSON Schema Specification \- W3C, accessed June 8, 2026, https://www.w3.org/TR/vc-json-schema/
5. Verifiable Credentials \- UN Transparency Protocol, accessed June 8, 2026, https://untp.unece.org/docs/0.6.0/specification/VerifiableCredentials
6. EXPERIMENTATION WITH AI Gary Charness Brian Jabarian John A. List Working Paper 31679 \- NBER, accessed June 8, 2026, https://www.nber.org/system/files/working\_papers/w31679/revisions/w31679.rev1.pdf?utm\_source=PANTHEON\_STRIPPED
7. RFC 2119 Requirements Keywords \- Lizard-Spock, accessed June 8, 2026, https://lizard-spock.co.uk/rfc-2119-requirements-keywords.html
8. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels \- Ian Duncan, accessed June 8, 2026, https://www.iankduncan.com/projects/rfc-browser/2119
9. Pin Eight:Manual of Style/RFC 2119, accessed June 8, 2026, https://pineight.com/mw/page/Pin\_Eight\_Manual\_of\_Style\_RFC\_2119.xhtml
10. Applying Site Reliability Engineering to Autonomous AI Agents | Microsoft Community Hub, accessed June 8, 2026, https://techcommunity.microsoft.com/blog/linuxandopensourceblog/applying-site-reliability-engineering-to-autonomous-ai-agents/4521357
11. RFC 2119 \- Key words for use in RFCs to Indicate Requirement Levels \- IETF Datatracker, accessed June 8, 2026, https://datatracker.ietf.org/doc/html/rfc2119
12. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, accessed June 8, 2026, https://pike.lysator.liu.se/docs/ietf/rfc/21/rfc2119.xml
13. Verifiable Credentials JSON Schema Specification 2023 \- W3C, accessed June 8, 2026, https://www.w3.org/TR/2023/WD-vc-json-schema-20230613/
14. An Empirical Catalog of 63 LLM-Agent Budget-Overrun Incidents, with an Affine-Typed Rust Mitigation as a Case Study \- arXiv, accessed June 8, 2026, https://arxiv.org/html/2606.04056v1
15. Token Budgets: An Empirical Catalog of 63 LLM-Agent Budget-Overrun Incidents, with an Affine-Typed Rust Mitigation as a Case Study \- Hugging Face, accessed June 8, 2026, https://huggingface.co/papers/2606.04056
16. Token Optimization and Cost Management for ChatGPT & Claude | IntuitionLabs, accessed June 8, 2026, https://intuitionlabs.ai/articles/token-optimization-chatgpt-claude-costs
17. The Black Box Recorder: Observability for the Agentic Era | TrueFoundry Engineering, accessed June 8, 2026, https://www.truefoundry.com/blog/agent-gateway-series-part-6-of-7-observability-for-non-deterministic-systems
18. The "Infinite Loop" fear is real. How are you preventing your agents from burning $100 in 10 minutes? \- Reddit, accessed June 8, 2026, https://www.reddit.com/r/AI\_Agents/comments/1qnavt9/the\_infinite\_loop\_fear\_is\_real\_how\_are\_you/
19. AI Agents for Production | Tool-Using LLMs at Scale \- Tensoria, accessed June 8, 2026, https://tensoria.fr/en/services/ai-agents
20. W3C Verifiable Credentials: How They Work \+ Use Cases 2026 \- TRUE Original, accessed June 8, 2026, https://www.trueoriginal.com/insights/verifiable-credentials-w3c-guide
21. Generation Next: Experimentation with AI \- The University of Chicago, accessed June 8, 2026, https://bfi.uchicago.edu/wp-content/uploads/2023/09/BFI\_WP\_2023-126.pdf
22. Generation Next: Experimentation with AI Gary Charness, Brian Jabarian, and John A. List \- National Bureau of Economic Research, accessed June 8, 2026, https://www.nber.org/system/files/working\_papers/w31679/w31679.pdf
23. Building with extended thinking \- Claude API Docs, accessed June 8, 2026, https://platform.claude.com/docs/en/build-with-claude/extended-thinking
24. Thinking mode in Claude 4.5: All You need to Know | by CometAPI | Medium, accessed June 8, 2026, https://medium.com/@mkteam/thinking-mode-in-claude-4-5-all-you-need-to-know-353235942182
25. Handling of thinking output in Anthropic API · karthink gptel · Discussion \#1232 \- GitHub, accessed June 8, 2026, https://github.com/karthink/gptel/discussions/1232
26. AIHubMix OpenAI Compatible Interface Upgrade — Deep Support for Claude Thinking, Caching, and Beta Features, accessed June 8, 2026, https://docs.aihubmix.com/pt/blogs/aihubmix-openai-upgrade-claude
27. Structured outputs \- Claude API Docs, accessed June 8, 2026, https://platform.claude.com/docs/en/build-with-claude/structured-outputs