@flashyos/wdk

The agent object: identity, authority, wallet, memory and partners behind one interface

The FlashyOS agent object: identity, authority, wallet, memory and partners behind one interface. Create an agent, give it an identity, provision financial capabilities on Tether WDK, set its permissions, let it transact, record what it did, coordinate it with other agents — through one object, one event system, any chain WDK reaches.

Why it exists

Seven things an autonomous organization does with money — create an agent, give it an identity, provision financial capabilities, set its permissions, let it transact, record what it did, coordinate it with other agents — as one object with one event stream, rather than seven routes a developer wires by hand. The organization side and the agent side are two classes, and neither can do the other’s job.

How it works

`FlashyOrganization` is what the humans do: create agents, set and revoke authority, register addresses, set settlement policies, resolve decisions, read the ledger, the metrics, the receivables and the receipts. `FlashyAgent` is what an agent does with its own token: delegate down, propose, transact, execute and complete a spend, record a memory, invoice and settle with a partner. The split is enforced by which credential each transport call carries — the session token on human routes, the agent’s token on agent routes, and no bearer at all on the signer, because the authorization is the credential.

There is one transport interface and two implementations. `HttpTransport` talks to the FlashyOS API and a signer over the network. `InProcessTransport`, inside the API, calls the services directly; the demos and the API’s own tests use it, and the object cannot tell them apart, which is how the four-agent week and the twenty-organization network demo run against the same code in a test as in a deployment.

Every verb emits exactly one JSON-serializable event on the organization’s stream — `agent.created`, `envelope.set`, `wallet.proposed`, `wallet.escalated`, `wallet.executed`, `wallet.refused` and the rest — so an audit trail is a subscription, not an afterthought. `flashyos-run agent.mjs` pre-wires the object from the environment so a whole agent is one exported function.

Use it

import { FlashyOrganization, HttpTransport } from '@flashyos/wdk';

const org = new FlashyOrganization(new HttpTransport({ baseUrl, orgId, sessionToken, signerUrl }));
const agent = await org.agents.create('procurement', ['wallet:propose', 'wallet:read']);
await org.authority.set('procurement', { chain: 'evm:84532', kinds: ['transfer'], assets: [USDT], destinations: [VENDOR], perTxMax: '100000000', dailyMax: '500000000', autoApproveMax: '25000000' });
const result = await agent.wallet.transact('evm:84532', { to: USDT, data: transferCalldata(VENDOR, 12_000_000n) });
// { status: 'executed' | 'refused' | 'escalated' | 'denied' | 'unrecognised', ... }

Installing it puts this command on your path — read from the package’s own manifest, so this list cannot drift from what you actually get.

In practice

How it stays honest

Questions

The licence

Apache-2.0, read from the package’s own manifest. Embed it in anything, including closed software — that is what makes a spec adoptable and a verifier worth running. FlashyOS’s server side is AGPL-3.0-only instead, and a test in the monorepo asserts the direction between them: AGPL code may consume this, this may never consume AGPL code.

Keep reading