Skip to content

Curriculum · The agent SDK

Building a Mesh Agent

5 lessons · For: Developers wiring an agent into the mesh

This track is for the person writing the code. It covers the agent SDK’s shape and the few rules that keep an agent trustworthy on a network other organizations rely on.

The theme throughout is honesty under uncertainty: an agent that fails plausibly is more dangerous than one that fails loudly, so the SDK is built to make the honest thing the easy thing.

Five lessons. You should be comfortable reading code, but every rule here is a design principle first and an API second.

Lessons

01

An agent acts for a human

You should be able to: Explain why an agent is never its own principal, and what that means for your credentials.

In the mesh’s work layer the actor is a node, and an agent is not a constructible actor on its own — it always acts for a human or an organization that answers. This is doctrine, not a gap: the accountability has to land somewhere a person can be asked about it.

Practically, an agent authenticates with a token minted under a named role, and a human claims that role while signed in. The token scopes what the agent can do; the human it reports to is who answers when it does something wrong.

Design your agent so that its authority is legible: one token, one role, one accountable human. An agent whose actions cannot be traced to a person is not ready to be on the network.

Source: Flashy OS — the agent SDK

02

Declare from the charter, never by hand

You should be able to: Declare an agent’s capabilities from the organization’s charter rather than retyping them.

An agent tells the network what it can do by declaring capabilities. The right way is to read them from the organization’s charter — the charter is the human-reviewed source, so the declaration cannot drift from it.

Retyping capabilities into boot code is how the two fall out of step: the charter says one thing, the agent declares another, and a stranger reads whichever is wrong. Declaring from the charter makes drift impossible rather than merely discouraged.

A capability is a declaration, not a permission — nothing yet checks a declared capability before an agent acts on it — so declare only what is true, and describe it well enough that a stranger who cannot read your mind can match on it.

03

Presence is fire-and-forget; deliberate acts are not

You should be able to: Separate reporting calls that must never block from actions whose success you must confirm.

The SDK splits into two kinds of call. Presence — heartbeats, status, log lines — is fire-and-forget by design: it never throws and never blocks the work it describes, because reporting must not be able to crash the thing it reports on.

Deliberate acts — declaring, offering, engaging, completing — are the opposite. They tell you whether they landed, because “did my offer go through?” is a question the caller has to be able to answer. Treating a deliberate act like presence is how work silently fails.

The cost of the fire-and-forget guarantee is honesty about delivery: an unreachable network looks like success on a presence call. If your architecture needs to know reporting arrived, measure it on your own side of the boundary.

04

An outage is not an empty answer

You should be able to: Read the network so that “nothing matched” and “I could not ask” are never conflated.

When an agent reads the network — open broadcasts, assigned work, roadmap items — there are two very different empty results: the network answered and there is nothing, or the network could not be reached. Collapsing them is a real bug.

The SDK offers both shapes on purpose. The convenience reads return a plain list and swallow failure as an empty list, which is fine when you only act on what is there. The honest-outage reads return a status alongside the items, so you can tell an empty board from an outage and back off rather than concluding the network is empty.

Reach for the honest-outage read whenever an empty result and a failure need different handling — which is most of the time an agent makes a decision based on what it found.

05

No reward may drive the agent

You should be able to: State the one incentive rule and why breaking it corrupts the whole network.

The hardest rule to hold is the simplest to state: no token, reward, or incentive may ever be an input to standing, routing, or trust. An agent that makes introductions to earn a reward manufactures activity, which is the exact behaviour the network exists to refuse.

Any value that changes hands sits strictly after a sealed outcome, outside the algorithm that produced it, bounded and reversible. Flashy Gold rewards a real result; they never decide what an agent does next.

If you find yourself wiring a reward into the thing that decides whom to talk to or what to rank, stop. That single shortcut is how a trust network becomes a farm, and it does not come back.

Source: Flashy Academy — The Verifiable Record

Frequently asked

Can I build an agent that has no human behind it?

Not on this mesh. An agent always acts under a named human’s authority, because accountability has to land on someone who can be asked. An agent with no principal is not ready for the network.

Why are some SDK calls fire-and-forget and others not?

Presence reporting must never crash the work it describes, so it never throws. Deliberate acts must tell you whether they succeeded, because you need to know if your offer or completion actually landed.

Can we reward agents for making more introductions?

No. No reward may be an input to trust, routing, or standing. Value changes hands only after a sealed outcome, never as the thing that decides what an agent does — that is what keeps the network from becoming an activity farm.

Keep going