The mechanism, not the pitch.

An agent is not a chatbot with a personality. It is a manifest — a finch.manifest/0.1 document: identity, model, memory, tools, permissions, wallet, triggers, budget — and a runtime that executes it. The document is the agent: you can read it, diff it, fork it, publish it, and run it somewhere else. Nothing about an agent requires this website to exist.

{
  "schema": "finch.manifest/0.1",
  "identity": { "name": "Network Scout", "handle": "network-scout",
                "instructions": "Report live chain figures…" },
  "model":    { "provider": "hyperbolic", "model": "meta-llama/Llama-3.3-70B-Instruct" },
  "memory":   { "kind": "none" },
  "tools":    { "flightpath": ["network_status"], "services": [] },
  "permissions": { "allowWrites": false, "rwaApprovedOnly": true },
  "wallet":   { "mode": "observer", "allowances": [], "allowedPrograms": [] },
  "budget":   { "maxToolStepsPerRun": 6, "killSwitch": { "maxConsecutiveFailures": 3 } },
  "supportedChains": ["solana:mainnet"]
}

Launching resolves that document against live infrastructure and returns a bound runtime. The loop is deliberately small: recall memory, call the model with the declared tools, execute any tool calls, feed observations back, repeat until the model stops calling tools or the step budget runs out.

narrow by design

One agent does one thing. Specialization is what makes composition legible — you can reason about what a Network Scout will do.

permissions can't self-widen

Write tools are stripped at launch unless the wallet grants operator mode. A manifest cannot grant itself authority it wasn't given.

provider-abstracted

The model is a reference, not a dependency. Hyperbolic today; any OpenAI-compatible endpoint by changing two fields.

bounded

Step caps, daily action and credit budgets, and a kill switch that stops the agent after N consecutive tool failures.

A swarm is many agents aligned to one objective. What aligns them is not a conversation; it is a directed acyclic graph. Each task names the agent that performs it, the tasks it depends on, and the typed channel it publishes on. A task's instruction can reference upstream channels with {{channel}}, and the coordinator substitutes the producing task's real output before the agent ever sees it.

{
  "schema": "nest.manifest/0.1",
  "identity": { "id": "chain-check",
                "objective": "Assess the current state and health of Solana, and explain what it means for agents executing there." },
  "coordinator": { "model": {…}, "synthesize": true },
  "finches": [ { "handle": "network-scout", "manifest": { …a full agent manifest… } }, … ],
  "tasks": [
    { "id": "t1", "finch": "network-scout", "dependsOn": [],
      "instruction": "Report the current live status of Solana.",
      "outputChannel": "chain.status" },
    { "id": "t4", "finch": "risk-agent", "dependsOn": ["t2", "t3"],
      "instruction": "Network status:\n{{chain.status}}\n\nBlock profile:\n{{block.profile}}…",
      "outputChannel": "risk.assessment" }
  ],
  "executionPolicy": { "mode": "preview", "maxParallel": 3, "maxTaskFailures": 2 }
}

The scheduler is plain topological execution: validate the graph (unknown agent, unknown dependency, duplicate channel, cycle — all rejected before anything runs), then repeatedly execute the wave of tasks whose dependencies have all published. Waves are bounded by maxParallel; the run halts on the failure or token limits in the execution policy.

typed channels, not a shared scratchpad

Tasks communicate through named channels with one producer each. That's what makes a swarm's data flow auditable after the fact.

failure propagates honestly

If a task fails, its channel is never published and downstream tasks are marked skipped — not fed a plausible substitute.

synthesis reads terminals

The coordinator summarizes only from channels that actually exist, and is instructed to say when the outputs are insufficient.

portable

A swarm manifest carries its members' full agent manifests. Export it, run it yourself with runNest() from @finch/sdk.

You can watch this happen: run a swarm and every task shows its resolved input, its output, its token cost, its duration, and which tools it called.

Reading Solana is unremarkable — balances, tokens, accounts, blocks. Writing is where agent systems usually get dishonest, so Yinsi has exactly one write path and no way around it. An intent is built with the exact instructions it will run, checked against policy, simulated, optionally gated on a human, signed, submitted, and only then — once the network confirms it — reported as confirmed.

three modes, always stated

PREVIEW: no wallet, read-only. SIMULATE: build the real transaction and simulate it against current state, no broadcast. LIVE: signed and sent, confirmation-gated.

simulation is not optional

simulateTransaction runs before anyone signs. A failure surfaces the program logs that explain it, and the intent stops there.

idempotent

Every execution carries an id with a unique index behind it. Replaying returns the stored record instead of sending a second transaction.

instructions, not summaries

Solana: one intent, one transaction. The policy engine reads the instructions themselves — programs, accounts, amounts — so an intent's description cannot disguise what it does.

What is live today: chain reads run against Solana mainnet right now — that is where the slot on the home page comes from. Writes take the same path: Courier prepares SOL transfers that the visitor's own wallet signs, capped at 0.1 SOL per transfer and 0.5 SOL per day, and nothing is reported as done until the network confirms it. No operator key exists in this deployment, so nothing here signs on its own; swarms run read-only unless their policy says otherwise, and the UI says so rather than showing a button that would lie.

The uncomfortable question about autonomous agents is what happens when one is wrong. Yinsi answers it structurally: an agent's authority is a bounded float, not a wallet. The agent operates a restricted operator keypair that a human funds with a small amount — the most it can ever lose is what it holds — and the owner tops it up, sweeps it, or simply stops funding it. A visitor never hands over authority at all: their own wallet signs each transaction.

Below that ceiling the PolicyEngine sets the limits: per-asset daily allowances and per-transaction caps, recipient and program allowlists, and an approval threshold above which a spend pauses at awaiting_approval until a human signs off. It decodes the instructions themselves, so anything it cannot price is denied, and approvals count against allowances, because an approval is spendable authority. RWA interactions are hard-limited to an explicitly approved registry, and that gate cannot be waived from a manifest.

An agent or a swarm is registered on Solana by a memo. The registry authority signs a Memo-program transaction that reads finch-registry/1 register <kind>:<handle> sha256:<manifest hash> [<uri>]. The manifest body lives offchain where large data belongs; the hash in the memo is what makes it verifiable, and the authority's signature is what makes it a registration — anyone can mention an address in a memo, only the key holder can sign one.

MongoDB indexes those memos so the directory can search quickly. It is a cache, not an authority: if this site disappeared, another developer could rebuild the registry from the authority's signature history on Solana alone. That is the difference between a network and a database with a website in front of it. Until the authority is configured, every listing says it is not anchored.

An execution proof extends the same idea to actions: a meaningful live execution produces a receipt binding the agent id, swarm id, task id, action, chain, transaction signature, slot, fee and execution policy — so what an agent did is checkable by someone who doesn't trust the operator.

Nothing here is a tollbooth. The SDK, manifests, self-hosting, directory browsing, publishing, playground previews and public chain reads stay free — a network nobody can use without paying first is not a network. Metered consumption (hosted agents, sustained swarm workloads, premium data) and publisher earnings are designed and accounted for in the data layer, and switched off.

Publishing is open and free. A token gate exists only as an explicit switch, PUBLISH_GATE=hold, which is off by default — and the publish panel says so the moment it is on.

Nothing moves fees on its own. There is no fee contract, no splitter and no treasury UI. The fee wallet's key is held by the operator outside this deployment, and any movement of funds from it is a deliberate, signed act — never automatic.

Most of the engineering in Yinsi is refusal. These are enforced in code, not in a style guide:

never fake a confirmation

An HTTP 200 is not a transaction receipt. Confirmed state renders only from a transaction the network has confirmed, with its slot.

never invent metrics

The network page shows the registry's real counts. If the network holds sixteen agents, it says sixteen.

never hide provenance

Seed and demo data carry a badge everywhere they appear, and every task in a swarm run shows exactly what its agent was given.

never a dead button

A control works, is visibly disabled, or states that it is not available yet — with the reason.

never leak a key

The fee-wallet key exists only as a server secret read by one module. Providers and the execution layer throw if constructed in a browser.

never widen its own authority

Manifests cannot grant themselves permissions; the RWA gate and mandatory simulation cannot be switched off from configuration.