Technical Architecture
How can we build truly sovereign agents?
All of the pieces needed for true sovereignty of agents can be solved using the following architecture.
1. Update Control Architecture
A proper architecture for agent updates requires rethinking how code changes are proposed, approved, and applied to running agents. Any solution must eliminate single points of control while maintaining transparent oversight of the update process.
1.1 For today’s agents
Today, agent capabilities are at a stage where they can’t reliably update their own code and behavior - even the best LLMs struggle to modify their own logic without introducing errors or unintended consequences. Until agents reach a level of sophistication where they can safely evolve their own code, a decentralized human committee provides the best balance between autonomy during operation and supervised updates for improvement and maintenance.
The protocol operates in distinct epochs, each representing a period where the agent runs with a specific code version and maintains exclusive control of its resources through TEE-generated keys.
Between epochs, a structured update process occurs:
-
Pre-Update Phase
-
Current TEE signals approaching epoch end
-
Committee members can begin proposing updates
-
Updates must be submitted to public code repository
-
-
Update Approval
-
All proposed changes require m-of-n committee signatures
-
Updates must be open-source and publicly verifiable
-
Approved changes are merged into the dockerized codebase
-
-
Transition Phase
-
New keys generated within new TEE instance
-
New TEE instance spins up with updated code
-
Current (new) TEE validates new instance attestation
-
State and memory transferred with cryptographic proofs (more details in the next section)
-
Resource Migration
-
Previous TEE transfers funds to new instance
-
Or automatically moves funds to committee multisig
-
Committee can only access funds during update window
-
1.2 End state
As autonomous systems evolve to achieve sophistication levels where they can reason about and modify their own code with perfect reliability, surpassing 99.99% of human programmers, this committee-based architecture will become obsolete. These systems could then safely evaluate potential improvements, formally verify the correctness of changes, and implement updates autonomously while maintaining their core objectives and security properties—much like how humans can learn and adapt their behavior while preserving their fundamental values, but with far greater precision and reliability.
At such an advanced stage, the evaluation and modification of long-term objectives and memory through collective decision-making remains an open question. The administrative structure might focus specifically on these core modules or on predefined sets of high-criticality actions (for example, all transfers exceeding $100,000 within a 10-second window).
These foundational objectives might function similarly to a nation’s constitution—largely stable but capable of evolution through participatory oversight. As these intelligent systems gain access to millions of databases, database operations must align with rules established in this constitutional framework. This necessitates structuring databases as zkdatabases, with proofs verified on-chain in a trustless manner. The same principle extends to proofs produced via TEE execution, where precompiles enable on-chain verification.
This framework ensures that the “world state” consistently aligns with protocols established through collective decision-making by all system participants.
2. Memory + State Continuity Architecture
Agents accumulate knowledge and state during operation, building an understanding of ongoing conversations, tracking pending tasks, and managing resource states. This accumulated state represents a critical component of the agent’s identity—much like human memory shapes who we are. When an agent updates, its state requires careful handling; it cannot be discarded or casually transferred. Just as wiping a person’s memory would fundamentally alter their identity, improper handling of agent state transitions could compromise the agent’s ability to maintain consistent, long-term behavior and objectives. To address this challenge, the state transition system must implement cryptographic guarantees that preserve and authenticate state between epochs, while preventing unauthorized modifications during updates.
Transition Package Structure
Each transition package bundles everything needed to prove state authenticity: merkle trees of the actual state data, signatures proving it came from the authorized previous TEE, and attestations proving the TEE was running approved code. The new TEE instance acts like a zero-trust verifier - it checks every aspect of the package before accepting the state or generating any new keys.
The verification-before-keys approach creates an unbroken chain of trust between epochs. Each new epoch’s keys are cryptographically tied to verified state from the previous epoch, making it impossible to initialize a new instance with fabricated or modified state data.
3. Tool Use Architecture
While agents struggle with complex multi-step tool interactions, significant progress has been made in teaching LLMs to use tools effectively. Frameworks like ToolBench (with 16,000+ APIs), AgentInstruct, and StableToolBench demonstrate different approaches to expanding tool use capabilities.
Current frameworks achieve 80-90% success rates for simple API calls but drop to below 70% for complex multi-step operations. Three main categories of tools have been explored:
-
Direct API Integration - allowing agents to call external services
-
Web Interaction - enabling browsing and form manipulation
-
Smart Contract Interaction - for blockchain operations
Tool use framework. A key feature of modern tool use frameworks is their ability to ingest new tool documentation. Developers can upload API documentation, PDFs describing tool usage, and example interactions. These are automatically parsed and integrated into the tool library, allowing agents to learn new tool capabilities without requiring code changes. During updates, the committee can approve new tools to be added to the agent’s capabilities through this standardized tool library. The library includes tool specifications, usage patterns, and safety constraints derived from the uploaded documentation. While current systems require updates for new tools, research is progressing toward agents that can learn to use new tools during operation.
The key challenge remains reliable multi-step tool use - especially when tools need to be combined in novel ways or when handling errors and edge cases. However, frameworks like AgentInstruct show promise in improving these capabilities through better training approaches and documentation processing.
4. Secure World Observation Architecture
Agents need reliable, verifiable sources of information about the external world. While some data sources provide cryptographically signed feeds that can be directly verified, most websites don’t offer such guarantees.
Regular APIs and websites don’t provide secure, verifiable data feeds. While some high-stakes data sources like price oracles and weather services do provide cryptographically signed data that agents can directly verify, most web content has no built-in verification. A two-tier approach solves this by using Notary TEEs as trusted intermediaries for regular websites - they observe the web content directly and provide signed attestations about what they saw. This lets agents get verifiable data from any website while the website itself doesn’t need to change how it works.
For signed data sources, the agent directly verifies cryptographic signatures. For standard websites, Notary TEEs act as trusted observers, providing Authenticated Data Feeds (ADFs) with attestations about website content. These feeds include:
-
Content hash
-
Timestamp
-
TEE attestation
-
TLS session proof
5. Restricted Website Use
Today’s internet infrastructure is built on a fundamental assumption: the primary actors are humans interacting with servers. This assumption permeates every aspect of our digital infrastructure, from authentication systems like CAPTCHA to trust protocols like SSL/TLS certificates. However, we are witnessing a profound shift in how the internet is used. Agents can not access websites at large and get blocked.
The traditional question of “is this a human or a bot?” that CAPTCHA attempts to answer is becoming obsolete. Instead, servers need to answer a more nuanced question: “Is this a good agent or a bad agent?” This question, however, is significantly more complex than simple bot detection.
The distinction between “good” and “bad” agents cannot be reduced to simple heuristics or behavioral patterns. A good agent for an e-commerce platform might be one that does not hoard inventory in cart and respects rate limits, while a good agent for a content platform might be one that provides accurate content indexing while respecting copyright. The definition of “good” varies dramatically based on context, use case, and the specific requirements of each service.
Furthermore, traditional certificate authorities (CAs) only verify domain ownership and identity. They don’t make any assertions about behavior, reliability, or safety. As we move towards an AI-native internet, we need a new kind of certificate authority – one that can make meaningful assertions about an agent’s behavior, reliability, and compliance within specific contexts.
The Agent Certificate Authority
The MVP Agent Certificate Authority (ACA) will address these challenges. Instead of making broad assertions about an agent’s nature, the ACA certifies specific workflows - well-defined interaction patterns between agents and services. This workflow-centric approach allows for:
-
Context-Specific Evaluation: Each workflow is evaluated against criteria that are meaningful for its specific use case and context.
-
Behavioral Verification: Through extensive testing in controlled environments, the ACA can make strong assertions about how an agent will behave in production.
-
Reliable Compliance: By certifying specific workflows rather than agents in general, the ACA can verify compliance with rate limits, data handling requirements, and other service-specific constraints.
-
Clear Accountability: The certification process creates a clear chain of responsibility and provides mechanisms for certificate revocation if agents deviate from certified behavior.
The goal is to provide a concrete path forward for building trust infrastructure that meets the needs of an AI-native internet. By establishing clear standards and processes for certifying agent workflows, it becomes possible to enable the safe and efficient deployment of AI agents while protecting the integrity and security of internet services.
6. Smart Contract Deployment
Smart contract deployment by autonomous agents presents many security challenges. While agents can write and deploy contracts, smart contract vulnerabilities are notoriously difficult to detect - even skilled human auditors frequently miss critical bugs. Before an agent commits funds to a contract, its code must undergo thorough review by a committee and pass automated security checks.
-
Inside TEE:
-
Private key generation and storage
-
Contract bytecode generation/verification
-
Transaction signing
-
-
Outside TEE:
-
RPC node connections
-
Gas estimation
-
Transaction broadcasting
-
The TEE handles all sensitive operations: key generation, bytecode creation, and transaction signing. External systems manage network interactions like gas estimation and broadcasting. Most critically, the committee review process ensures no high-risk contracts are deployed without thorough security analysis. This creates multiple layers of protection: cryptographic security from the TEE, code quality verification from automated tools, and expert human oversight for complex security considerations.
The deployment architecture splits responsibilities between secure TEE operations and external network interactions:
End State
Once AI agents achieve superintelligent capabilities - being able to reason about and modify smart contracts with near-perfect reliability that surpasses virtually all human programmers - this committee-based architecture may become unnecessary. Such advanced agents would be able to safely deploy smart contracts without the need for external audits or vulnerability checks. While technical safety would be assured, humans could still maintain oversight through their personal AI agents, which would conduct lightweight reviews focused on ensuring the contracts align with human preferences and intentions.
7. Secure Key and State Recovery Architecture
TEE-based agents face a critical challenge: the risk of permanently losing access to their keys and state. This can happen if a specific TEE technology becomes compromised, if cloud providers deprecate TEE offerings, or due to software bugs. While TEEs provide strong security guarantees, relying on a single TEE creates unacceptable recovery risks.
This challenge can be addressed through automatic key and state recovery using secret sharing across diverse TEE platforms. By distributing shares across different TEE technologies, cloud providers, and geographic regions, agents can maintain access even if some platforms become unavailable.
The recovery process is fully automated through cryptographic verification:
-
When a new TEE instance needs to recover keys (due to hardware failure, migration, etc.), it generates an attestation proving its legitimacy
-
It contacts available backup TEEs, each running on different platforms
-
Each accessible backup TEE verifies the requestor’s attestation
-
If valid, they provide their shares of the keys and state
-
Once k valid shares are received (even if some TEEs are offline), the new TEE can reconstruct its complete keys and state
-
The reconstructed state is verified against original merkle roots
This creates a robust recovery system that:
-
Survives individual TEE platform failures
-
Requires no human intervention
-
Maintains security through attestation verification
-
Automatically rebalances shares if TEEs become unavailable
The key requirement is removing human decision-making from the recovery process entirely - security comes from cryptographic verification and TEE attestations.