Animus/ Blog
runtime ↗animus.team ↗github
← All posts
FIELD NOTES · 8 min read · The Animus Team

Dynamic subjects are the missing data model for agent operations

Agent teams do not just need better prompts. They need a better model for the work their agents are supposed to understand, route, update, block, finish, and audit. Dynamic subjects give every unit of work, from tasks and requirements to blog posts, CI jobs, trigger events, and future custom kinds, the same lifecycle semantics. That is what turns agent automation from a pile of one-off workflows into an operating system for work.

The problem is not execution. It is the work object.

Most agent stacks start with tools and workflows. Give the agent access to a terminal, a repo, an issue tracker, maybe a queue, then tell it what to do. That can work for demos and narrow automations, but it breaks down when the system needs to operate continuously across many kinds of work.

What exactly is the agent working on?

Sometimes it is a ticket. Sometimes it is a requirement. Sometimes it is a content brief, a CI failure, a customer escalation, a trigger event, a knowledge node, or a deployment check. Each one has its own shape, its own status values, its own source system, and its own lifecycle rules.

Humans solved part of this problem with structured work trackers. GitHub Issues, for example, can track ideas, feedback, tasks, bugs, sub-issues, dependencies, labels, milestones, and project views. That structure matters because people need to sort, prioritize, relate, and complete work. Agents need the same thing, but in a form that is machine-routable across systems.

A queue message is too thin. A prompt is too temporary. A bespoke JSON blob is too isolated. Agent operations need a durable work object.

A subject is the durable unit of work

In Animus, that durable unit is a subject.

A subject is a dispatchable work object with a normalized shape: an id, kind, title, optional description or body, status, priority, assignee, labels, hierarchy links, optional URL, timestamps, and backend-owned custom JSON. Animus subject backends also share normalized dispatch statuses that agents can depend on across tools: ready, in-progress, blocked, done, and cancelled.

That sounds simple, but it changes the architecture.

Instead of building every workflow around a specific tracker or storage system, Animus routes subjects through installed subject_backend plugins. A backend declares the subject kinds it supports. It can claim exact kinds like task or requirement, or glob-style families like linear.*. Exact kind matches win over globs, duplicate claims fail, and the daemon sees one normalized subject shape regardless of where the data lives.

That means the orchestrator does not need to know whether a work item came from SQLite, Markdown, Linear, GitHub Issues, or a future custom backend. It can reason over the shared contract: kind, status, priority, labels, body, timestamps, and custom metadata.

This is the core of dynamic subjects. task and requirement are not the whole model. They are the first examples. A team can add blog, knowledge.node, ci.job, incident, trigger.github, or a vertical-specific kind without rewriting the orchestration layer.

The BaaS analogy, applied to agent operations

The closest analogy is Backend as a Service, but for autonomous work.

Firebase and Supabase made app development faster by giving teams a shared data foundation plus operational primitives around it. Firebase positions Firestore as a scalable NoSQL database for storing and syncing data with rich data models and queryability, and Cloud Functions as backend code that can run in response to events. Supabase gives every project a Postgres database that becomes the foundation for Auth, Storage, Realtime, and Edge Functions, with triggers and database webhooks for reacting to row changes.

Animus applies that pattern to agent operations.

Not BaaS for end-user apps. BaaS-style primitives for autonomous work.

The subject store holds the work objects. Subject plugins act as adapters and storage engines. Statuses describe lifecycle state. Watch implementations and daemon polling propagate changes. Workflows and agents become the compute layer that reacts to subject state.

That framing matters because it moves the platform conversation away from “Can this agent call a tool?” and toward “Can this operation be modeled, validated, routed, executed, and audited?”

Local, versioned, or external: the lifecycle stays the same

Animus subjects are not tied to one database.

The SQLite subject backend shows the local system-of-record path. Its README explains that many subject backends wrap external systems like Linear, Jira, GitHub Issues, or Notion, while animus-subject-sqlite owns the data in a local SQLite database with no upstream API, tokens, or rate limits. Its schema uses one table with fields for id, kind, title, body, status, priority, assignee, labels, parent id, custom fields, native status, status metadata, attachments, and timestamps.

That is not just a task table. It is a general subject store.

The Markdown subject backend shows a different mode. It stores one Markdown file per task, uses strict YAML frontmatter for structured fields, keeps the body as human-readable context, writes deterministically for clean git diffs, and implements subject/watch with file watching.

That gives teams a useful choice. Work objects can be local database rows, versioned Markdown files, or external tracker records. The storage changes. The lifecycle contract stays the same.

For agent operations, that is the important part. A workflow should not have to care whether the subject lives in a repo, a local database, or an external SaaS tool. It should care that the subject is ready, has the right kind, carries enough context, and can be updated safely.

Schema-driven work is what makes automation composable

Dynamic kinds are powerful only if they stay structured.

That is where schema matters. JSON Schema exists to describe the structure and constraints of JSON data, support validation, provide machine-readable and human-readable documentation, improve data quality, and enable interoperable data exchange. The Model Context Protocol takes the same direction for agent tools: tools have an inputSchema, may provide an outputSchema, and structured tool results are expected to conform when a schema is provided. Anthropic’s tool-use documentation also describes custom tools with an input_schema and strict tool use so calls match a schema exactly.

The same principle applies to subjects.

A prose task description can tell an agent what a human wants. A schema-driven subject can tell the system how to route and validate the work.

With schema-aware subjects, agents and workflows can:

  • Select the next runnable object by kind, status, and priority.
  • Require specific fields before dispatch.
  • Route blog subjects to editorial workflows and ci.job subjects to remediation workflows.
  • Preserve backend-native metadata in custom without losing normalized lifecycle semantics.
  • Validate transitions into blocked, done, or cancelled.
  • Generate queues, dashboards, and audit logs from one shared shape.
  • Let new plugins add domain-specific fields while still satisfying the common subject contract.

That is the unlock. The agent does not just read a prompt and act. It operates on a typed, durable object with state.

Dynamic subjects turn work into a graph agents can operate on

Once work is modeled as dynamic subjects, the system can grow beyond a ticket queue.

A requirement can spawn tasks. A blog brief can move from research to draft to review. A CI failure can become a remediation subject. A trigger event can create follow-up work. A knowledge node can be updated after an investigation. Each object can have its own kind-specific schema and metadata, while sharing the same basic lifecycle: ready, in-progress, blocked, done, cancelled.

That makes orchestration simpler and more durable.

A daemon can list ready subjects. A workflow can claim one, run phases, write findings back to the body, add labels, and move the subject forward. A reviewer can inspect the same card. A future workflow can pick up the updated object without losing context.

This is also where Temporal is a helpful comparison. Temporal workflows are durable executions of workflow definitions, with event history as the source of truth for replay and recovery. Animus subjects sit beside that execution model as the durable work-object layer. They are the things being worked on, changed, blocked, completed, and audited.

Execution durability matters. So does work durability.

What to do next

If you are building agent operations, do not start by asking only which model or tool runner to use. Ask what your work object is.

Can an agent list it, claim it, validate it, route it, update it, block it, finish it, and audit it? Can a different workflow pick it up tomorrow? Can a new kind of work enter the system without a rewrite?

That is what dynamic subjects are for.

They give agent-native operations a shared data model: flexible enough for tasks, requirements, blog posts, knowledge nodes, CI jobs, trigger events, and custom future kinds, but consistent enough for automation to trust.

The missing layer in agent operations is not another prompt. It is the subject store.

Sources