Docs/HyperAgent/Core Concepts

Core Concepts

This page explains how HyperAgent should be read relative to the Hyperkit whitepaper (v1.2.0) and the public HyperAgent repository. It separates strategic architecture, operational Studio flow, and the closed-beta support boundary.

Problem frame

The whitepaper hypothesis is workflow fragmentation: teams still pay a recurring tax to move between specification, generation, audit, simulation, and deployment tools, often redoing chain-specific glue for each release. HyperAgent targets that coordination cost. It is not only a code generator. It is an orchestrated path where each stage has a defined input, output, and gate.

Four layers

Strategy and documentation use the same layer names: client, gateway, orchestrator, backend services. The client captures intent and shows artifacts. The gateway enforces identity and routing. The orchestrator sequences work. Backend services perform verification, persistence, and deployment preparation.

Abstraction boundary

Hyperkit abstracts workflow coordination. It does not promise that chain physics, RPC endpoints, Tenderly projects, or deployment frameworks disappear. Position HyperAgent as the workflow layer above those integrations.

Workflow semantics

A request enters through Studio, passes the gateway for authentication and routing, is planned into ordered stages in the orchestrator, and then hits backend services for generation, static analysis, simulation, storage, and deployment preparation. Each layer owns a narrow responsibility so you can see where policy applies, where context is created, and where evidence is produced.

Studio operational flow

The whitepaper Figure 2 flow is reproduced below for consistency across strategy and engineering docs.

Documented Studio path: wallet, BYOK, validation, workflow stages, simulation, deployment gate.

Agent pipeline

The HyperAgent README describes a service-oriented agent graph: SpecAgent (with versioned spec lock), design and proposal agents, CodegenAgent with streaming guardrails, autofix and audit agents using Slither, Mythril, MythX, and Echidna where configured, TenderlySimAgent, DeployAgent, VerifyAgent, and MonitorAgent. Agents communicate with defined schemas; A2A and ERC-8004 registries apply where the deployment wires them. Treat this list as the reference pipeline, not as a guarantee that every stage is enabled in every environment.

Verification is not a slogan

Automated tooling reduces risk but does not replace human review on high-value contracts. The docs describe where tools run in the workflow, not a certificate of correctness.

Studio surfaces

The whitepaper lists the documented Studio modules:

Dashboard for workflows, deployments, metrics, and onboarding
Workflows for run creation, monitoring, status, logs, and results
Contracts for generated Solidity and ABI artifacts
Deployments for records and explorer links
Settings for BYOK key management
Payments for x402-backed handling on supported SKALE Base flows

Scope boundary

The architecture narrative is multi-chain. The closed-beta implementation narrative is narrower: wallet-based identity, deployment, and payments on SKALE Base Mainnet and SKALE Base Sepolia unless a page states additional support. When reading roadmap language elsewhere in the ecosystem, map it back to this boundary before assuming production readiness.

Topic deep dives

Specification to generation

Intent, spec lock, and artifact generation with workflow state as the source of truth.

AI generation

Verification

Audit stages, tooling, and gates in the orchestrated path.

Auditing

Deployment-aware output

Deployment preparation, records, and handoff-ready artifacts.

Deployment

x402 payments

Payment walls and HTTP402 semantics in supported flows.

x402 payments

Workflow mechanics

Runs, steps, retries, and how the control plane exposes progress.

Workflows