As a Tech Lead
Keep the team graph healthy — resolve contradictions, turn findings into decisions, and coach good filing habits.
You sit between architects and developers. You do not need to file every memory yourself — but you do need the team's graph to stay usable: contradictions resolved, findings promoted to decisions, and stale claims caught before they mislead the next session.
This guide is about usage patterns, not workspace permissions. For who can override or supersede someone else's memory, see When memories disagree.
The scenario
Your team owns the payments-platform domain. Three developers file memories while shipping. An architect filed constraints last month. You open Monday's session and need to know what changed, what conflicts, and what still needs a decision.
Orient for the team pulse
Developers orient scoped to their own recent activity by default. As a tech lead, you often want the whole team's view:
"Orient on payments-platform — show me everyone's recent activity, not just mine."
The digest surfaces what others changed while you were away — including contradictions involving your memories and memories of yours that someone superseded. Your agent flags these; you do not run manual conflict audits unless something specific needs digging into.
When you need a health check before a big change:
"Orient on payments-platform — if anything looks stale, run a stale audit before we file new memories."
Turn findings into decisions
A common graph problem: the team files findings but never closes the loop with a decision. Open findings pile up and the next orient reads like a research dump.
| State | What to do |
|---|---|
| Finding is still being investigated | Leave it — or file an issue if it is blocked |
| Team settled on a direction | File a decision and connect it to the finding |
| Finding was wrong or outdated | Ask the owner to supersede, or supersede yourself with a required reason if you are an Editor |
Example after a team discussion:
"File a decision: we're using Redis for webhook deduplication — connect it to the duplicate-events finding from last week."
That one link turns evidence into a settled choice the whole team can orient on.
Resolve contradictions — do not ignore them
When orient surfaces owned contradictions — two memories that conflict and you own at least one side — decide:
"The Redis dedup decision holds — the in-memory approach was a spike result only, not a production choice."
Your agent records the resolution. Leaving contradictions open means the next developer's agent may get two conflicting answers and ask again.
If the conflict is someone else's memory and you believe yours is wrong, talk to them first. Supersede and override are deliberate ceremonies — not something you do silently. See When memories disagree.
Coach the team on memory types
You do not need to police every filing, but a few nudges keep the graph clean:
| Mistake | Fix |
|---|---|
| Observation filed as decision | Split into finding + decision, or revise the type |
| Same decision filed three times | Pick the best one; supersede or forget the duplicates |
| Sprint tasks in Recordari | Redirect to the issue tracker; file decisions and findings here |
| Architectural choices in the project domain | Fine if the team agreed — otherwise point architects at the right domain |
In code review or standup, a light prompt goes a long way: "Worth filing that as a decision?" or "Didn't we already have something on webhook auth — search before we duplicate?"
Domain hygiene — what tech leads watch for
| Signal | Action |
|---|---|
| Orient reports stale memories | Run a stale audit; archive or revise what no longer holds |
| Orphan memories with no connections | Link to related decisions, or forget if they were noise |
| Open issues older than a sprint | Close, promote to decision, or escalate to the architect/PO |
| Contradictions in the digest | Resolve in your next session — do not leave them for developers to hit cold |
You are not the graph administrator. You are the person who notices when the graph stops being trustworthy and fixes the highest-impact problems.
A Monday — step by step
1. Team pulse
"Orient on payments-platform — everyone's activity since Friday."
2. Digest shows a contradiction
"Show me both sides of the webhook auth contradiction — which memories conflict?"
Decide and tell your agent which holds.
3. Promote a settled finding
"File a decision: composite index on (user_id, created_at) for the events table — connect it to Jamie's slow-query finding."
4. Before a risky change
"Check for stale memories in payments-platform before we refactor the webhook pipeline."
5. End of week
You resolved one contradiction, linked two findings to decisions, and ran one stale audit. The team did the rest while coding.
Workspace role vs job role
Your job is tech lead; your workspace role might be Owner, Editor, or Reader:
| Workspace role | What it means for graph hygiene |
|---|---|
| Editor | You can supersede and override with ceremony; you archive others' nodes when needed |
| Reader | You read and coach filing habits — you cannot write; escalate changes to an Editor or the memory owner |
| Owner | Same as Editor for graph work, plus key and member management in the admin portal |
Job-role guidance and workspace permissions are different things. See When memories disagree for the permission matrix.
Standing rules (planned)
Per-role setup templates are planned but not shipped yet. Until then, file standing memories for constraints the whole team should inherit:
"File a standing rule: run a stale audit on payments-platform before any production migration."
When role templates ship, this guide will link to them.
Next steps
- As a developer — filing while coding
- As an architect — durable design memory
- When memories disagree — supersede, override, and ownership
- MCP Tools Reference — audits, orient scopes, memory types