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

Subjects as the Control Plane for AI Work

Most AI agent programs stall for the same reason: the work lives in one place, the context in another, the priorities in someone’s head, and the agent output in a chat transcript nobody can operate from later. The fix is not a longer prompt. It is a control plane: typed, durable subjects for tasks, repos, requirements, incidents, decisions, and knowledge, connected in a graph that agents can read, act on, and write back to.

The problem with prompt-driven operations

A prompt is a request. It is not an operating model.

That distinction starts to matter when one team is managing multiple products, repositories, customers, incidents, and release trains. A human can sometimes hold that mess in their head. An agent cannot. If the agent only sees a task title and a few pasted notes, it has no reliable way to know which repo is affected, which requirement changed, which incident raised the priority, or which decision superseded the old plan.

This is why so many agent workflows collapse into manual babysitting. Operators spend their time restating context, choosing what should run next, checking whether the agent used the right source, and copying useful results back into the system of record.

That is not autonomy. That is chat with errands.

A better pattern is to make the work itself addressable. Every unit of work, context, and knowledge becomes a typed subject with state, metadata, relationships, and history. Agents stop acting on loose prose and start reconciling durable records.

Subjects are the control-plane objects for AI work

Kubernetes gives us a useful analogy. Its control plane makes global decisions about the cluster and responds to cluster events. Kubernetes objects are persistent entities that represent cluster state, often separating desired state in spec from observed state in status.

AI operations need the same separation.

A task subject can carry the desired outcome, priority, labels, workflow, current status, and final result. A repo subject can carry ownership, deploy surface, active work, risk, and links to docs. A requirement subject can carry acceptance criteria, priority, dependent tasks, source customer, and implementation status. A knowledge subject can carry a fact, decision, incident note, design rationale, or external source with provenance.

The important shift is that operators no longer manage agents by crafting one-off prompts. They manage typed state. Agents become workers that select eligible subjects, run the right workflow, and write results back to the same durable record.

That is the control-plane model: subjects hold intent and state, workflows reconcile them, and agents perform scoped work.

Typed subjects solve the “everything is a task” problem

Most work systems eventually outgrow flat task lists.

GitHub Issues is a good example. Issues can represent ideas, feedback, tasks, or bugs. They support sub-issues, dependency relationships, labels, milestones, issue types, and project views. Kubernetes has a similar metadata pattern with labels and selectors, which let operators organize and select subsets of objects.

AI work needs that same typing, but across more than tickets.

A repo is not a task. It needs dependency scans, ownership metadata, release awareness, and code workflows. A requirement is not a task. It needs decomposition, traceability, acceptance criteria, and test coverage. A blog topic is not a task. It needs research, drafting, review, and publication. An incident is not a task. It needs triage, mitigation, postmortem, and follow-up.

If everything is flattened into “task,” agents either get too little structure or too much irrelevant context. A kind field is not cosmetic metadata. It is the dispatch key for workflows, permissions, schemas, and valid state transitions.

For an operator, this means the system can ask better questions:

  • Is this a repo that needs a maintenance workflow?
  • Is this a requirement that needs decomposition before implementation?
  • Is this a blog subject ready for drafting because research is complete?
  • Is this incident blocked by an unresolved decision?
  • Is this task eligible, or is it waiting on a dependency edge?

Typed subjects turn a pile of requests into an operating surface.

The graph is the grounding layer, not just a search index

A subject model becomes much more powerful when subjects are connected.

The W3C RDF model represents information as triples: subject, predicate, object. The same resource can appear in many triples, which is what lets a graph expose relationships between facts. SPARQL is designed to query graph patterns across diverse data sources.

That maps cleanly to AI operations. An agent should not only search for similar text. It should traverse explicit relationships:

  • A repo implements a requirement.
  • A task is blocked by an issue.
  • A decision supersedes an older note.
  • An incident affects a product.
  • A test validates an acceptance criterion.
  • A blog draft cites a research source.

This is the difference between retrieval and grounding.

Vector search is useful when the question is, “What text looks relevant?” A subject graph helps when the question is, “What is connected to this work, and why does it matter?” Microsoft’s GraphRAG documentation makes this point directly: baseline vector RAG can struggle when an answer requires connecting pieces of information through shared attributes. GraphRAG responds by extracting entities, relationships, and claims, building a knowledge graph, clustering it, summarizing communities, and using those structures at query time.

For operators, that matters because the hardest agent questions are rarely isolated:

  • Which ready tasks touch repos with a high-priority release this week?
  • Which requirements have implementation tasks but no tests?
  • What decision changed the acceptance criteria for this feature?
  • Which products depend on this deprecated API?
  • Which knowledge notes were used to justify this agent output?

A queue cannot answer those questions. A subject graph can.

Prioritization becomes graph-aware

A normal queue can sort by status and priority. That is useful, but too shallow for multi-product operations.

A subject graph can rank work using connected context. Priority can be inherited from a linked customer, product, requirement, or incident. Risk can be inferred from repo ownership, release timing, dependency criticality, or incident history. Blockers can be represented as first-class edges instead of buried in prose. Freshness and confidence can live on knowledge subjects, so stale context does not silently steer agent behavior.

This is where the control plane starts to pay off.

Imagine two tasks both marked ready. One touches a low-risk internal tool. The other touches a repo linked to an active release and a requirement with no test coverage. A flat queue may treat them as peers. A subject graph can route the second one first, attach the right context, and require a stricter workflow.

The operator does not have to write a perfect prompt explaining all of that. The relationships carry the context.

Dispatch should follow subject kind and graph context

Once subjects are typed and connected, workflow dispatch can become explicit.

LangGraph’s documentation distinguishes workflows with predetermined code paths from agents that dynamically choose tools and processes. It also describes routing, orchestrator-worker patterns, persistence, streaming, and human-in-the-loop support for stateful agent systems. That distinction is helpful: not every AI operation should be a free-form agent loop.

A practical control-plane architecture looks like this:

  1. A subject router selects work by kind, status, labels, priority, and graph relationships.
  2. A workflow runtime runs deterministic phases where possible.
  3. Agent workers operate on one scoped subject and fetched graph context.
  4. The workflow writes back status, labels, findings, artifacts, links, and provenance.
  5. The graph is updated with validated facts, decisions, and relationships discovered during the work.

MCP fits naturally at the boundary. It describes itself as an open standard for connecting AI applications to external systems such as data sources, tools, and workflows. In this model, MCP is the connector layer. Subjects are the control-plane state those connectors expose and mutate.

The result is not “an agent that can do anything.” It is a system where agents do specific work against typed state, with the right tools and permissions for that subject.

Write-back turns output into operational memory

The biggest failure mode in agent systems is not bad generation. It is lost work.

An agent researches a topic, but the findings stay in a transcript. A coding agent discovers a design constraint, but it never reaches the requirement. A reviewer finds a risk, but it is not attached to the repo, release, or task. The next agent starts cold, and the operator becomes the memory layer again.

Write-back fixes that.

The agent should update the subject it worked on with the result: status, labels, findings, decisions, linked artifacts, and sources. A research agent writes sourced findings to a blog subject. A coding agent writes implementation notes and links a pull request to a task or requirement. A review agent writes risk labels, blockers, or approval decisions. A documentation agent updates knowledge subjects and links them to affected repos or features.

This turns a one-off run into an auditable state transition.

It also gives future agents something better than hidden chat history. They can cite the subject, source URL, commit, decision, or artifact they used. Operators can inspect the card and understand what happened, why it happened, and what should happen next.

A concrete multi-product example

Suppose an operator manages three products across several repositories. A customer request becomes a requirement subject. That requirement links to two repo subjects, three implementation tasks, one design decision, and a release subject.

The graph now carries operational meaning:

  • The requirement defines the acceptance criteria.
  • The repo subjects identify where the work lands.
  • The tasks represent implementation steps.
  • The decision explains a constraint.
  • The release subject raises priority.
  • Test subjects can prove coverage.

When an agent looks for work, it does not just pick the next ready ticket. It sees that one task belongs to a requirement tied to an upcoming release, touches two repos, and lacks a linked test. The router can choose the implementation workflow, attach the requirement and decision context, require test generation, and ask a human to review if the repo is sensitive.

After the work, the agent writes back to the task, links the pull request, updates status, adds notes, and creates or updates related knowledge subjects. The control plane is now smarter than it was before the run.

That is the compounding effect. Every useful agent action leaves behind structured state for the next action.

Guardrails make the graph safe to operate

A subject control plane needs discipline. Without it, the graph becomes another place for drift.

Use explicit schemas for each subject kind. If repo, requirement, incident, and blog subjects all evolve informally, agents will misread fields and write inconsistent updates.

Track freshness, provenance, and confidence. A stale repo ownership edge or outdated decision can mislead an agent as easily as a bad prompt.

Limit traversal. Graph retrieval can pull too much context. Use kind-aware depth limits, relation allowlists, and source filters so agents get the context they need without drowning in the graph.

Scope write permissions. Agents should not be able to mutate every subject in every way. Subject updates should be typed, validated, auditable, and gated where risk is high.

Keep humans in the loop for decisions that change product direction, customer commitments, production systems, or security posture. The control plane should make those gates visible, not hide them.

The operating model: state transitions over typed subjects

The future of AI operations will not be built on larger prompt libraries alone. Prompts are useful, but they are not enough to coordinate durable work across products, repositories, requirements, incidents, and knowledge.

Operators need a control plane.

Typed subjects give agents an addressable unit of work. The subject graph gives them grounding and relationships. Workflow dispatch gives them the right process. Write-back gives the organization operational memory.

That is the shift: agents become reliable when their work is expressed as state transitions over typed subjects.

If your agents keep losing context, repeating work, or leaving results in chat, do not start by rewriting the prompt. Start by asking what your control plane knows, what it can route, and what your agents are allowed to write back.

Sources