Actuate
The zero-trust runtime for agentic commerce
About
The problem it solves AI agents can reason well, but most products still break at **autonomous multi-agent execution**: coordinating specialists, paying for actions, enforcing limits, and proving what happened without constant human intervention. Actuate solves this with an agentic system where: - A **Planner** agent decomposes a user request and coordinates specialists. - **Rider, Foodie, and EventBot** execute domain tasks (research, browsing, event registration) and return structured outputs. - Agent-to-agent/API actions run through a **payment-aware execution loop** (`402 challenge -> pay -> retry`) with minimal human involvement. - Every run is streamed live and replayable, so behavior is inspectable end-to-end. ## What People Can Use It For - Running real autonomous workflows that require multiple specialist agents. - Delegating agent permissions safely while still letting agents transact. - Monitoring live operations and replaying runs for debugging, demos, and audits. - Handling failures (scope violations, budget exhaustion, revocation) with clear enforcement and recovery behavior. ## How It Makes Existing Tasks Easier and Safer - **Easier:** orchestration, specialist execution, payment flow, and evidence are unified in one control plane. - **Safer:** every request is policy-gated (identity, nonce, session, passport, scope, service, rate, budget, payment). - **More accountable:** each action can be traced to payment proof and receipt artifacts. ## Where Kite AI Fits Kite is a major part of the system because it provides the rails that make this agentic model trustworthy: - **x402-style pay-per-action flows** for autonomous calls - **On-chain passport/session identity** for verifiable agent permissions - **On-chain receipt logging** for settlement traceability So the product’s center is the **agentic orchestration system**, and Kite is the core infrastructure that makes that autonomy secure and economically operable. Use of AI tools and agents Actuate is built as a **dynamic multi-agent system**, not a single chatbot. AI tools and agents collaborate in four phases: ### 1) Planning (Orchestrator Agent) - A planner agent (LLM-driven) receives the user request. - It uses tools like `get_weather` and `plan_agents` to decide what specialist agents are needed. - Instead of hardcoding the team, it generates an agent manifest at runtime (roles, tasks, scopes, browser needs). ### 2) Agent Spawning (Identity + Permissions) - The system spawns specialist agents on demand. - Each spawned agent gets: - its own wallet - funded token balance - on-chain passport policy - delegated session access - This gives every agent a verifiable identity and scoped permissions before execution starts. ### 3) Parallel Specialist Execution - Spawned agents run in parallel with role-specific prompts/tasks. - If needed, agents get live browser tools (navigate, search, extract, click, form fill, screenshot) through Firecrawl sessions. - Each agent reports structured findings back through a `report_results` tool. - Failures are isolated per agent; other agents continue. ### 4) Synthesis + Delivery - The planner/synthesizer agent aggregates all specialist outputs. - It compiles a final itinerary and sends it to the user via email tooling. - The whole run is streamed through SSE for live observability (agent spawn, status, thoughts, payments, browser state). ## How They Work Together The collaboration pattern is: 1. User request arrives 2. Planner decides team composition 3. System spawns authorized agents with on-chain identity 4. Specialists execute tasks concurrently with AI tools 5. Results are merged into one final response This architecture keeps the product strongly **agentic** (autonomous decomposition + parallel specialist execution), while using Kite-native identity/payment rails as the trust and transaction layer underneath.
How it's made
Challenges we ran into ### 1) Frontend/Backend Contract Drift (moving too fast) AI sped up prototyping a lot, but that created a real frontend/backend gap as we kept shipping features quickly. We’d add new backend event payloads, agent states, or response shapes, and parts of the UI would silently break or render stale assumptions. **How we fixed it** - Centralized shared contracts/types across services. - Standardized SSE event names and reducer mappings for new agent lifecycle events. - Added smoke checks so broken contracts show up before demo time. --- ### 2) x402 Schema Differences Across APIs Not every x402-style integration looked the same in practice. Some endpoints expected legacy headers, others newer headers, and some had different challenge payload formats. We also hit flows where a plain tx hash wasn’t enough for auth expectations. **How we fixed it** - Implemented dual header compatibility and normalized challenge/proof parsing. - Added facilitator-first verification with direct ERC-20 fallback. - Added graceful fallback behavior so planner execution continues even if one payment path is incompatible. --- ### 3) Sub-Agent Communication and Coordination Going from a static “few fixed agents” model to dynamic spawned sub-agents was a major systems challenge. The hard part wasn’t just spawning agents, it was getting them to coordinate, return structured outputs, and synthesize reliably. **How we fixed it** - Added a planning phase where the orchestrator defines a runtime agent manifest. - Added a structured reporting channel (`report_results`) for sub-agents. - Added orchestration phases + agent lifecycle events (planning, spawning, executing, synthesizing) so coordination is observable and deterministic.