Teams

Who is the reference for what

Team member profiles give every person an evidence-backed picture of the areas they work in, a declared decision scope they write themselves, and a short team block compiled into what every agent reads first, so an assistant points at the right colleague instead of deciding for them.

Ask ChatGPT Ask Claude View as Markdown

An assistant that knows your codebase can still get one thing badly wrong: it decides something that was not its call. It renames a public field, changes a pricing rule, restructures a module, and it does so with no idea that a person on the team is the reference for that area and would have answered in one sentence.

Team member profiles close that gap. Each person in your organization gets a profile that answers a single question, who is the reference for which area, and a short version of that answer is compiled into what every agent reads before its first tool call.

A profile belongs to the team, not to a repository

The profile is organization scoped and workspace independent. Someone who is the reference for payments is the reference for payments whether the work happens in the API repository, the mobile app, or a service that did not exist last month. Tying it to one workspace would mean re-establishing the same fact per repository, which is how a directory goes stale.

Two halves, and only one of them is inferred

A profile has a derived half and a declared half, and the split is deliberate.

Derived: the areas you actually work in. Pathrule already records a short entry per piece of work, and it already knows who authored which memory and rule at which path. Those two counts, work logged against a path and knowledge authored at that path, are the evidence. Nothing else is read: not your code, not your commit messages, not how long anything took. The window rolls, so an area you left behind fades out of your profile instead of following you for years.

Declared: your decision scope. This one is typed by the person and never derived. Authority over a product decision does not follow from touching files, and a system that inferred it from activity counts would be inventing it. The person who touched the billing code most last month may be the last person who should be deciding a pricing rule. So Pathrule asks instead of guessing.

The same rule covers your display name, your pronouns and how available you are: your own words, in your own row.

You see your own profile, and you can correct it

The Members panel in Studio shows the team, and it shows you your own profile the way an agent will read it. A derived list you disagree with is not something to file a request about: you replace it with your own list of areas or tags, and yours wins. The presence of your list is what marks the answer as corrected rather than inferred, so nothing quietly overwrites it on the next derivation.

The database enforces the boundary rather than the interface. You can write your own row and nobody else's.

What the agent actually gets

Not the profile table. A short block, appended to the instruction files your agents read first, that looks like this in substance:

the team name, and the person the file belongs to, with up to three of their own areas
up to three colleagues, each with the single area they are the reference for
up to two declared decision scopes
one instruction: address the user by name, and when a decision touches another person's area, point at its owner instead of deciding for them

That last line is the point of the whole feature. A list of names with no instruction is data an agent scrolls past. So the instruction is reserved before anything else is measured, and if the block would end up with the instruction and nobody to point at, the block is dropped entirely rather than shipped as noise.

What the block cannot say

The block accepts names, paths, tags and a declared scope. There is no field for a performance claim, a speed claim, a quality claim or a seniority claim, and free text is capped in length and collapsed to a single line. This is structural rather than a review guideline: a compiled instruction file cannot grow a paragraph of opinion about a colleague here, because there is nothing for such a sentence to travel in.

It is also small on purpose, a fixed budget of around a hundred tokens including its heading. When there is more to say than the budget allows, whole lines are dropped from the least valuable end rather than a sentence being cut in half, so a trimmed block still reads as something an agent can act on. One block, once per file, never a second one.

Why it rides the compiled file

Pathrule has two ways to reach an agent: the compiled instruction files, read once at the start of a session, and the per-turn hook, which reaches the model on every prompt. The hook is the right channel for what changes with the request. This block does not change with the request, so paying for it on every prompt of a long session would be paying many times for one constant fact.

It sits at the very end of the file for a related reason. A cached instruction prefix is invalidated from the first changed byte onward, and team membership changes far more often than your workspace knowledge does. Keeping the volatile block last leaves everything above it byte identical when somebody joins.

Visibility is per person and defaults to being visible to your team. Setting your profile to private removes you from every team-facing read, including the compiled block, so no agent on the team is told what you are the reference for. The choice lives in the same row the profile does and the database applies it to every query, so there is no surface where a private profile leaks because one screen forgot to filter.