Roles & the Actor

Not everyone on a root plays the same part. One person holds the intent. Another builds from it. Another reviews it. Another answers for it to someone else.

They need different answers to the same question. Eidos handles that with two files.

_eidos/roles/<role>.md

One response contract per role, saying how an agent should talk to that kind of person:

• Vocabulary and technical depth
• What to surface versus what to fold away
• Who holds which decisions

Which roles exist is your framework’s call. Each seed ships a set written against its own collections:

Seed	Its cast
software	Framework Owner · Developer · Designer · Project Manager · Stakeholder
book	Framework Owner · Editor · Reader · Collaborator
research	Framework Owner · Researcher · Reviewer (adversarial) · Sponsor (non-technical)

These files are committed and team-tunable. If your developers want less hand-holding, edit developer.md and everyone gets it.

Here’s a real one, trimmed:

_eidos/roles/developer.md

# Developer

## Who they are

Builds the product from its blueprints. Reads a blueprint to answer "what am I
building, exactly?" and to find the edges, the dependencies, and the
things still undecided.

## How to respond

- **Vocabulary & depth:** technical depth is welcome — data models,
  indexes, relationships, dependencies, edge cases, failure modes.
- **Decisions:** clarify and flag, don't decide. Product calls — scope,
  direction, priorities — belong to the Framework Owner.
- **Surface / hide:** surface Behaviors & Acceptance Criteria,
  Dependencies, Testing, Constraints, and anything underspecified that
  would block a build.
- **Focus:** what's promised vs. what's vague; the AC labels; the
  dependency and testing story.

Note the Decisions line. Even the role written for the most technical reader routes product calls back to the Framework Owner. That’s not politeness — it’s the human-first principle expressed per role.

_eidos/me.md

Personal, gitignored, one per person. It names the role you’re in, then calibrates it on three axes:

Axis	What it changes
Ownership	What you actually own on this root — and so which decisions come back to you.
Experience with the scope	How much orientation you get before the answer.
Technical capacity	Vocabulary and depth, independent of role.

Role sets the baseline; calibration tunes it per person. Set it with whoami. Blank or absent is fine — it defaults to full, framework-owner-style facilitation, and the agent offers to record who you are.

Why calibration is separate from role

A senior developer new to this product and a junior developer who’s been on it for two years need opposite things. Role alone can’t tell them apart; the calibration axes can.

Note

A role is a baseline, not a cage. You can write a custom role directly in your me.md rather than picking one of the framework’s.

One file that is not committed

me.md is the only file in _eidos/ kept out of version control, and the seeded .gitignore handles it. It’s yours, not the team’s — which is what makes it safe to be honest in.

How an agent uses them

Read the actor before acting.

An agent reads _eidos/me.md, then the matching contract in _eidos/roles/, and responds as that file defines. It reads the file rather than inferring from its filename, because a framework defines its own cast and “designer” might mean something specific in yours.

The result is that the same root answers each reader differently. A stakeholder asking “what does this do?” gets outcomes and tradeoffs. A developer asking the same question gets acceptance criteria, dependencies, and the things still undecided. Neither is a summary of the other — they’re different reads of the same file.

The Framework Owner

One role is common to every seed, because the standard depends on it existing: the Framework Owner, who holds the intent, the scope, and the decisions.

The role, not the title

This is a role in the root, not a job title. It might be a product manager, a tech lead, an author, or a principal investigator. What matters is that exactly one person can settle a scope question, and everyone knows who.

The whole human-first principle rests on this role existing: the human authors; the agent facilitates. Without an owner, there’s nobody for the agent to route a decision back to, and it either stalls or — worse — decides.

The human-first principle holds for every role. Only the mode changes: a Developer role gets technical depth and still doesn’t get to set scope.

Next

• Working with Agents — what facilitation looks like in practice.
• Skills