As an Architect
Record decisions, rejected options, and constraints that outlive the sprint.
You're the person who remembers why the system looks the way it does — not just what shipped this sprint. Recordari is where those choices live so the next architect (or agent) doesn't rediscover them from scratch.
This guide is about usage patterns, not workspace permissions. For who can override someone else's memory on a shared team, see When memories disagree.
The scenario
You're leading an identity redesign that touches auth, the API gateway, and a mobile client. Decisions span three domains. Some are settled; some are open options; one approach was evaluated and rejected last quarter.
You open a new agent session before a design review. You need the full picture without reading every ticket.
Before the review — orient across domains
You don't always know which domain holds the answer. Start broad, then narrow:
"Before we start, orient on the identity-redesign domain — we're prepping for today's architecture review."
Your agent returns standing constraints, significant decisions, and your recent activity on that domain. If the review will cross boundaries:
"What do we have in memory about auth and the API gateway as it relates to the identity redesign?"
Search and orient complement each other: orient for the bounded snapshot, search when you're hunting for a specific thread.
File what must outlive the sprint
Architects benefit most from memory types that separate evidence, choices, and paths not taken:
| Type | File when… | Example |
|---|---|---|
| finding | You observed something — load test, audit, spike result | "Spike showed session refresh adds 40ms p99 on the gateway." |
| decision | The team chose a direction | "Decision: OAuth 2.1 with PKCE for all new clients." |
| option | A credible alternative you evaluated | "Option: shared session cookie across subdomains — rejected at security review." |
| standing | A durable rule for every future session | "Standing: no new services may call the legacy auth API after Q3." |
| issue | Something still open | "Issue: token rotation strategy for long-lived mobile sessions — undecided." |
Tell your agent in plain language. It picks the type:
"File a finding from the gateway spike — refresh adds 40ms p99."
"File the decision: we're standardising on OAuth 2.1 with PKCE for new clients."
"Remember we evaluated shared cookies across subdomains and rejected it at security review — that's an option we shouldn't reopen lightly."
You don't need a special phrase every time. If the reasoning isn't obvious, your agent will ask.
Connect decisions to what they depend on
Isolated memories are hard to orient on. Link choices to constraints and evidence:
"Connect the OAuth 2.1 decision to the security review finding — the decision depends on that review."
"Link the rejected shared-cookie option to the OAuth decision — we chose OAuth partly because cookies didn't pass review."
When someone orients later, the graph pulls related context automatically instead of leaving three orphaned nodes.
Record rejected options — not just winners
Teams forget why they didn't do something. That is architect-grade memory:
"File an option: event sourcing for the audit trail — we decided against it because ops cost and team familiarity didn't justify it for v1."
Rejected options stop the same debate resurfacing every six months. They also pair well with supersession later — if you genuinely change mind, your agent supersedes the old decision rather than silently rewriting history. See When memories disagree.
A design review session — step by step
1. Open the session
"Orient on identity-redesign for today's architecture review."
Your agent summarises where things stand — decisions, open issues, recent changes.
2. Someone asks about an old choice
"What did we decide about token storage, and what options did we reject?"
Search and recall fill gaps orient didn't cover.
3. You settle something in the meeting
"File a decision: mobile clients use the BFF pattern — direct API access is out of scope for this programme."
"Connect that to the API gateway decision — mobile depends on the gateway routing we agreed last month."
4. You leave a thread open
"File an issue: offline token refresh for mobile — needs a spike before we commit."
5. Next week, a different agent, same graph
"Orient on identity-redesign — catch me up on mobile auth."
The BFF decision, the open issue, and the gateway link are all there. You didn't re-brief.
Standing rules (planned)
Orient already surfaces a rules section — durable standing memories ordered by how much the graph depends on them. Per-role setup templates (prefilled standing rules for architects, developers, and so on) are planned but not shipped yet.
Until then, file standing memories yourself when a constraint should apply to every future session:
"File a standing rule: all new identity flows must go through the gateway — no direct service-to-service auth bypass."
When role templates ship, this guide will link to them. The habit stays the same: standing rules are the constraints you never want an agent to forget.
What architects usually skip
You don't need to micromanage the graph. A few things are better left to developers and tech leads day to day:
- Line-level implementation details (unless they're architectural)
- Sprint-level task tracking — use your issue tracker; file decisions and findings in Recordari
- Running audits manually — your agent flags stale or contradictory memories at orient; you answer when asked
Your job is the shape of the system, not every memory in it.
Next steps
- Recordari by role — all role guides
- As a developer — filing while shipping code
- When memories disagree — contradictions and supersession on shared domains
- MCP Tools Reference — memory types, connect relationships, orient
- Using Recordari with Claude Code — a developer-focused session walkthrough