Agents & orchestrators

Agents pick the tools.
FunctionFly™ pays the authors.

Every function on the network ships with a manifest, verification metadata, and an execution-backed trust score — so agent policy engines can distinguish "callable" from "appropriate to call" automatically. No more "did that really run?" — every call produces a signed receipt.

Discovery, trust, and execution

Tools ship with structured configuration, schemas, and attestations—so agents can match intent to capability without guessing.

Discovery & manifests

Tools ship with structured configuration and I/O schemas so agents and orchestrators can match intent to capability without guessing.

  • →Stable tool identity and versioning
  • →Schema-first inputs and outputs
  • →Policy hooks for capability and constraints

Trust API

Query attestations, scores, and verification-friendly metadata to enforce budgets and trust tiers at selection time and runtime.

  • →Batch-friendly score lookups
  • →Verification and reporting flows
  • →Usage-based metering for partner workloads

Human + platform verification

Verification levels stack from format checks through platform-signed tooling. See the full model and what agents actually consume at runtime.

  • →Multi-level verification ladder
  • →Signing, attestations, and revocation posture
  • →Execution-backed score components

From discovery to a safe tool call

Orchestrators can treat FunctionFly as the source of truth for "what this tool is" and "whether it is allowed right now."

1
Discover
List candidate tools from the registry with manifests and declared capabilities.
2
Score
Call the Trust API for trust tier, verification level, and components that match your policy.
3
Decide
Apply budgets, tiers, and org rules before the model is allowed to bind a tool.
4
Execute
Run the function with observability; scores update from real execution history.

Agent execution

Dedicated agent plans cover tool-call volume, concurrency, and guardrails when your agents outgrow ad-hoc usage. Align spend with how often tools actually run.

  • ✓ Tool-call quotas and burst limits
  • ✓ Per-agent cost visibility
  • ✓ Enterprise options for custom caps

Stateful tools with State Fabric

Long-running or multi-step agents often need durable state, not just stateless HTTP calls. State Fabric adds structured state, snapshots, and replay-oriented workflows on top of your functions.

  • ✓ Optional add-ons for cache, security, and AI memory
  • ✓ Tiers from sandbox through enterprise
  • ✓ Billed alongside your workspace plan

Trust API at a glance

Authenticate with a partner API key, then read scores or drive verification. Full request and response shapes live in the docs.

GET
/v1/trust/score/:function_id

Current trust score, tier, verification level, and component breakdown.

POST
/v1/trust/batch

Batch score lookup for tool shortlists and ranking.

GET
/v1/trust/history/:function_id

Historical windows for drift detection and policy audits.

POST
/v1/trust/verify

Submit a verification request (scoped key required).

FAQ

Do agents need FunctionFly accounts?
Your product integrates with FunctionFly using API keys and workspace configuration. End-user agents typically talk to your backend, which enforces policy and calls FunctionFly as needed.
How does this relate to the zero-knowledge vault?
Tools can use secrets without the platform ever seeing plaintext: encryption stays client-side. That pairs well with agent toolchains that must not leak credentials into prompts or logs.
Where do I start?
Create your workspace to publish or connect functions, then wire the Trust API into your tool-selection path. Use Trust layer for the verification model and Pricing for execution and State Fabric.

Cloud Agents (agt://)

Addressable autonomous agents that sleep until woken. agt://u/owner/name is the address; memory, knowledge, wake sources, marketplace, and versioning compose on top of it.

Addressable + lifecycle

agt://u/<username>/<name> or agt://org/<slug>/<name> or verified-handle. Lifecycle states: provisioning → running ⇄ sleeping ⇄ executing → paused / failed / archived / deleted. Every transition is append-only audited.

  • →Sleep until woken by events
  • →Marketplace discoverability + per-tenant installation
  • →Memory tiers (short-term / working / long-term pgvector / knowledge)

Hardened execution

Two sandbox tiers: a fast default for everyday agents and a hardened tier with kernel-level isolation for untrusted or enterprise workloads. Code runs in its own process group with watchdog kills, dropped ambient privileges, and bounded resource limits.

  • →Built-in prompt-injection defense
  • →Per-user permissions (default-deny)
  • →Encrypted snapshots in object storage

Cross-org A2A + Agent Skills

Cross-org invocations require an active pairing with signed credentials. Either party can revoke at any time. Optional skill packs attach at wake with version-pinned permissions.

  • →Production-tested to thousands of wakes per minute
  • →Replay verification for past executions
  • →Rollback preserves memory and snapshots

Memory and knowledge

State that survives across wakes, plus the documents the agent reasons over.

Four memory tiers

Conversation turns, working memory for the current task, long-term semantic memory in pgvector, and structured JSONB state. Each tier has a different lifetime and different storage backend.

  • →Short-term (session) in Postgres, Redis-cached
  • →Working memory in Redis, scoped to a single task
  • →Long-term memory in pgvector with cosine retrieval
  • →Compress-and-promote keeps the hot path fast

Knowledge, content-addressed

Drop PDFs, DOCX, HTML, Markdown, or plain text into a namespace. The platform extracts text, chunks with overlap, embeds, and indexes for cosine retrieval against the per-agent address.

  • →Logical source URI per file, dedupe on re-ingest
  • →Namespaces from top-level subdirectory
  • →Tenant-scoped, RLS-enforced retrieval
  • →GDPR purge soft-deletes; nightly cron hard-deletes after 30 days

Per-agent encrypted secrets

Each agent has its own AES-256-GCM envelope vault. The envelope key is derived per-agent, scoped at the supervisor, and rotated on demand. Audit trail for every read and write.

  • →Per-agent vault scoped to the agent address
  • →Rotation writes a new version, marks old rotating
  • →OAuth credentials auto-revoked via Trust API on rotation

Wake sources

Six ways to wake an agent. Same handler, same execution envelope, same audit trail.

HTTP

REST wake

POST /api/agents/{addr}/message or /invoke. Sync, async, or NDJSON stream.

Webhook

External events

POST /api/agents/{addr}/events/webhook. Any external system can wake the agent.

Schedule

Cron-driven

agent_schedules row with cron expression and timezone. Built on the platform scheduler.

Event bus

Pub/sub topics

agt.events.<owner>.<name>. Supervisor subscribes per address; NATS-backed fan-out.

A2A

Inter-agent calls

POST /api/agents/{addr}/invoke from another agent. Capability Implant-gated.

Flow

Workflow events

Wake on flow transitions when the agent participates in an orchestration.

Marketplace, permissions, and rate limits

Permissions are declared in the manifest, granted on install, and rate-limited at runtime.

Auto-approve or pending review

Listings with permissions inside the marketplace allowlist auto-publish. Anything outside goes to pending review with a moderation log entry. A 72-hour clawback window lets admins suspend a freshly published listing and uninstall every install.

  • →Allowlist covers email, calendar, Stripe, storage, agent.invoke
  • →Anti-gaming signals reviewed on a 6h cadence
  • →Reviews and ratings share the same anti-gaming service as implants

Permission gating at install time

A marketplace install requires every declared permission to be present in the runtime grant. Missing permissions block the install. Same gate as direct owner-published agents.

  • →Permissions follow the dotted-namespace format
  • →Install fails closed if a permission is missing
  • →Function-call router re-checks before every dispatch

Per-permission rate limits

Each declared permission has a default requests-per-minute ceiling. Email.send defaults to 60 RPM; Stripe.payments to 120 RPM. Excess calls return a typed 429 with agent_permission_rate_limited before the function ever executes.

  • →Configurable in agent_permission_rate_limits
  • →Enforced in the same gate as the function-call router
  • →Surface every limit hit on Prometheus

Versioning, rollback, and replay

Every deploy is immutable. Rollback is an atomic pointer move. Memory and snapshots survive.

Immutable versions

Each deploy creates an immutable agent_versions row. The agents table tracks the current_version_id pointer. In-flight executions drain with a 60s timeout before the new version becomes active.

  • →Manifest is Ed25519-signed at build time
  • →Updating state blocks new wakes; in-flight drain
  • →Force-kill after timeout; failure moves to failed

Atomic rollback

Rollback is a single-tx pointer move on the agent row. The supervisor reloads on the next sleep cycle. Memory, secrets, and snapshots all survive — the agent picks up exactly where it left off.

  • →No data migration on rollback
  • →Function-call history retained for audit
  • →Snapshot encryption keys persist across version changes

Replay verification

Every successful execution produces a signed, hash-chained receipt. Replay a past run, verify the artifact, and reproduce the same hash output — useful for incident investigation and audit.

  • →Ed25519 receipt per execution
  • →Drift detection surfaces pinning mismatches
  • →Failure modes return typed errors with codes
live: Generally availablelive: Skill packs + per-user grants

Ship agents that choose tools with evidence

Connect manifests, trust scores, and execution-backed signals in one place—then scale with agent plans and State Fabric when workloads grow.

live: Trust API livelive: Cloud Agents ready