Skip to content

Agency Model

When people say “an agent did the work”, they usually mean a vendor model accepted a prompt, called some tools, and returned a result. Stallari treats that as the simplest case of a much wider mechanism. Agentic work in Stallari is composed from typed primitives, gated by a tool-surface authoriser, and recorded in a durable audit trail. The user always knows what was asked, what was authorised, what ran, and what changed.

Stallari’s user-facing mental model starts with one role: a Chief of Staff that helps you act on your own information. You ask in Chat. You enable a workflow. You schedule a recurring job. The Chief of Staff understands the request, picks the right approach, and reports back.

Specialised workers exist behind that surface — they coordinate inboxes, summarise notes, prepare briefings, run integrations. The user does not need to recite their catalogue. Stallari surfaces operators as earned detail once a workflow makes them visible, not as a roster the user must learn before anything useful happens.

A workflow is a directed graph of typed steps, not a free-form prompt that a model interprets at runtime. Each step has a declared shape: input schema, output schema, retry policy, error handler.

PrimitiveRole
SequentialOne step after another; the next runs only when the previous completes.
ParallelIndependent steps run together and join at a barrier.
ConditionalThe graph picks a branch based on a predicate evaluated against prior output.
Fan-outOne step generates a batch; the runtime spawns a worker per item.
CompensationA reversal step paired with a forward step; the runtime invokes it on rollback.
Error handlerA typed catch that decides retry, escalate, or fail.

Pack authors compose workflows by declaring the graph. The runtime owns scheduling, persistence, retry, and reporting. Authors do not write loops, locks, or queues by hand.

Every skill declares the tools it can call before it runs. The declaration is part of the skill manifest, not a runtime decision made by the model. The default surface is empty: a skill cannot read a file, hit a network endpoint, or shell out unless its manifest names the capability.

This serves two ends. The user gets a readable list of what each skill is permitted to do — no implicit authority. The model gets a smaller working surface — only the tools it needs for the job appear in its context, which keeps prompts cheap and intent legible.

When a skill requests a tool the user has not authorised, the runtime asks. The authoriser is two-gate: the user grants the broad capability once (for example, “this skill may write to my vault”), and the runtime then checks each call site against the granted scope. A skill cannot widen its surface mid-run by asking the model nicely.

Some work mutates the world. Skills that send mail, file issues, write to the vault, or call third-party APIs cross from inference into action. Stallari treats these crossings as deliberate events.

ClassExampleDefault posture
Local readList a folder, query the vault index.Granted when the skill’s manifest declares the surface.
Local writeAdd a note, edit a note’s frontmatter.Granted in a named scope; review queue surfaces edits to human-written body content.
Network readFetch a URL declared in the manifest.Granted when the manifest declares the endpoint set.
Network writeSend mail, post a webhook, create an issue.Two-gate: capability granted in Settings; per-call check against scope on dispatch.
ShellRun a subprocess.No default. Skills run in a restricted shell with a deny-list and a seatbelt profile.

Risk-class metadata flows with the skill into the runtime. A skill that asks for network-write of a class the user has not approved does not run — it lands on the review queue with the requested action, the cited reasoning, and a clear approve / reject control.

Every dispatch produces a durable record. The record opens when the work starts, accumulates events as the workflow advances, and closes when the workflow terminates — either by completion, by user cancellation, or by error.

The Activity surface in the app reads from this record. So does any future post-hoc inspection: a user can ask “what did the briefing job do yesterday?” and Stallari can answer from the recorded events, not from a model’s recollection. Tracks are idempotency-keyed, watermarked, and append-only. They survive restarts. They survive instance migration. They survive the model that produced them being deprecated by its vendor.

The audit trail is also the substrate for precedent. When the platform makes a judgment call on the user’s behalf — selecting a provider, choosing a recipient, deciding a classification — the call is recorded with its reasoning. The next session can read the precedent, choose to follow it, or override it. This is how continuity accumulates over time without the user having to re-teach the platform every Monday.

The agency model is not architecture trivia. It is what makes Stallari legible to a user who wants to trust it with consequential work.

  • A run is not a black box. The graph is declared, the tools are scoped, the side effects are authorised, the record is durable.
  • A failure is not a mystery. The error handler ran or didn’t; the compensation step rolled the world back or didn’t; the audit trail shows the boundary.
  • An expansion is not a rewrite. New capabilities arrive as new primitives or new tool surfaces, not as a fork of the runtime.

Stallari aims to be the substrate a human can stand behind in front of a regulator, a partner, or a future version of themselves. The agency model is what makes that possible without turning every dispatch into a manual review.