agents are an implementation detail

the word agent has become a category, a feature, and a pitch. it is also an implementation choice. that distinction matters because companies rarely wake up wanting an agent. they want research to arrive with evidence, requests to reach the right person, projects to keep their context, and repetitive work to stop consuming the week.

starting with the agent makes the technology the main character. starting with the work makes the outcome the main character.

names create boundaries

when a company says it builds agents, people reasonably expect a certain kind of product: a model with tools, a loop, and enough autonomy to pursue a goal. that can be the right architecture. it can also be far more machinery than the problem needs.

a reliable system for a piece of knowledge work might be an agent. it might instead be a form that gathers better input, a search index that makes existing knowledge usable, a workflow that moves an artifact through clear states, or a dashboard that puts a decision and its evidence in the same place.

the user should not have to care which one it is. the system should earn its complexity.

begin with the shape of the work

before choosing a model or framework, map what actually happens.

• where does the request begin?
• what context is needed to act on it?
• which decisions are repeatable and which require judgment?
• where does the work wait, get copied, or lose information?
• what must remain visible to the person accountable for the outcome?

this map usually reveals that the task itself is only one part of the problem. the rest is context gathering, translation between tools, coordination, review, and follow-through.

an agent can help with several of those steps. it should not be asked to hide them.

use the lowest sufficient autonomy

autonomy is useful when the route to an outcome cannot be fully specified in advance. research is a good example: the system may need to follow evidence, revise a question, or choose a different source. a fixed workflow is useful when the route is known and consistency matters more than improvisation.

good systems often combine both. deterministic software establishes the boundaries, state, permissions, and audit trail. models handle the parts that benefit from interpretation. people make the decisions where context, consequence, or taste matters.

that composition is less dramatic than a fully autonomous demo. it is also much closer to how dependable work gets done.

build for the outcome, not the label

we expect agents to become ordinary components of software. some will be visible. many will sit quietly inside products, alongside databases, queues, search, and rules. calling every such product an agent will eventually be as useful as calling every product a database app.

subintern is interested in the broader problem: building better systems for knowledge work. agents are part of that toolkit, but they do not define its limits.

the useful question is not whether a product has an agent. it is whether the system gives the work a better shape.

that means less time reconstructing context, fewer handoffs that drop important details, clearer decisions, and more work reaching a real conclusion. the implementation can change. that standard should not.