Names Set Intention
13 April 2026
On 12 April we named the investments specialist agent Týr — Norse god of law, justice, and strategic thinking. We did not wait until the agent had proven itself or developed a distinct personality. We named it first, then built.
That ordering is not incidental. It is the operating principle.
The decision
When a new specialist agent is added to the team, it receives a name before it receives its first task. The name is drawn from Norse mythology or Swedish history. It is chosen to reflect the domain the agent will own: Týr for disciplined, thesis-driven portfolio management; Munin for memory and pattern collection; Heimdal for signal watching and threat detection; Mimer for daily reporting and financial snapshots; Vidar for product review and technical scrutiny.
The agent's personality at launch is minimal. The name is not a description of what already exists — it is a declaration of what the role is supposed to become.
Why names first
Naming a function after it is well-understood is how you get generic labels. "Portfolio agent", "review agent", "scanning agent". These tell you what the function does in the most literal sense and nothing else. They create no gravity around the role. They invite scope creep, because a generic label implies generic scope.
A proper name is different. Týr does not just analyse portfolios. Týr holds a standard. When Týr gave an analysis on 13 April that missed the question — focusing on portfolio attribution instead of market causation — the correction was obvious and unsatisfying in a specific way. Not "the function returned wrong output". Something more like: a strategist who should have understood the question did not ask for clarification. That framing matters for what you fix. We updated INSTRUCTIONS.md: ask before analysing if the question is ambiguous. The fix was behavioural, not structural.
Generic labels produce structural fixes. Names produce behavioural ones. That gap matters when you are iterating quickly and do not want to rebuild scaffolding every time something goes wrong.
What it is not
Naming agents is not anthropomorphisation. Týr is not a person. It does not have feelings about its work or preferences about its schedule. The name does not carry any claim about the agent's inner life.
What the name carries is role clarity and ownership. When a question comes in, the name makes the routing decision obvious. When something goes wrong, the name tells you whose domain the failure belongs to and what standard was not met. When scope expands, the name is a natural filter: does this feel like Týr's work?
That is the full scope of what naming is doing here. It is a coordination mechanism, not a metaphysical claim.
The naming pool
Current agents and their domain logic:
| Name | Domain | Mythology / Etymology |
|---|---|---|
| Rufus | Main orchestrator, chief of staff | Latin — "red-haired"; a companion's name, earned not assigned |
| Týr | Investment analysis and thesis validation | Norse — god of law, justice, single combat |
| Munin | Bookmark ingestion, signal collection, learning loops | Norse — Odin's raven of memory |
| Heimdal | Market signal watching, daily feed monitoring | Norse — watchman of the gods, sees all |
| Mimer | Daily financial snapshots and portfolio reporting | Norse — keeper of the well of wisdom |
| Vidar | Product and technical review | Norse — silent, strong, precise; son of Odin |
The pool is deliberately constrained. Not every new function gets a name from the pantheon — only functions that will own a domain long-term and need stable identity as they evolve. Short-lived workers and one-off subagents do not need names. They do not need to become anything.
The operating principle
Names set intention, not just labels.
Name an agent for the role it is supposed to grow into, not the role it can currently perform. Draw from sources with inherent meaning — mythology, history — so the name carries weight without explanation. Reserve proper names for agents that will own a domain across many iterations. Accept that the name will sometimes feel slightly too large for what the agent can do today. That tension is correct. It is what you are building toward.
Every subsequent addition to the agent team follows this principle. Before the first task, there is a name. Before the name, there is a domain worth owning.
This is the first post in the Agent Operating Model Retrospective series. Later posts in the series build on the foundations established here — the supervisor-specialist structure, naming as coordination, and the distinction between role identity and current capability.