Skip to content

v0.5

Choose a tag to compare

@amackera amackera released this 11 Aug 04:55
· 139 commits to main since this release

What's new

v0.5 is the "agents are configuration" release: an agent is now a prompt, a model, a tool selection, and a schedule — pure data, assembled over the API, with nothing to deploy. The direction is documented in docs/plan-agent-builder.md.

Major features

  • Per-agent tool selection — a ToolPolicy allowlist in model_config["tools"] scopes which worker tools an agent is offered (previously every agent saw every tool in the tenant). Enforced at advertisement and again at dispatch: an out-of-policy call gets an error result the model can recover from, plus a tool_call_denied audit event. Defaults open; existing agents unaffected
  • Cron triggers — schedules are Norns data: a triggers table (agent, cron expression, message, optional persistent conversation key) fired by a minutely Oban job with an atomic per-minute claim, so a trigger fires at most once per matching minute. Full CRUD at /api/v1/triggers, plus POST /api/v1/triggers/:id/fire to test a trigger without waiting for its schedule. Runs record trigger_type: "schedule"
  • Gards (worker affinity) — a gard pins all of a run's tool dispatch to exactly one worker, for coding agents and other filesystem-bound work (docs/gards.md). Atomic claim tokens (returned exactly once, on create), strict-equality dispatch in both directions, gard-filtered tool advertisement, gard-aware task queueing, per-run binding with child inheritance, resume-safe affinity, and gard-scoped idempotency keys. Workers register service ports over their channel; a /gards dashboard page shows status, connected workers, and port links

Fixes

  • Worker registry survives database hiccups — gard disconnect bookkeeping runs in an isolated task, so a DB error can't crash the GenServer holding every worker connection
  • Run detail (dashboard and API) surfaces the gard a run is bound to; runs show distinguishes scheduled runs from messages

Companion releases

  • nornsctl — triggers and gards command families; agents message --wait (block until the run completes, fails, or asks a question); nornsctl new --template default|slack-bot, with every scaffold shipping an AGENTS.md that teaches any coding agent the full build/test/debug loop
  • norns-sdk (Python) v0.3.0 — norns.run(agent, gard=, claim_token=), register_port, join-failure semantics (JoinError/GardDestroyed), and a fix for fresh installs broken by litellm 1.96.1's cp310-only wheels

Documentation

  • The cloud boundary decision: everything in this repo stays open source; the builder, provisioner, managed gards, and managed connectors are the planned hosted product — with managed connectors as the provisioner's first workload (docs/decision-log.md)
  • Roadmap v3 with steps 1–4 shipped; docs/gards.md v8 reflects the implementation

Upgrading

Two new migrations (triggers, gards): run mix ecto.migrate. All features are opt-in — existing agents, workers, and runs behave exactly as before.