Home and shared memory

Distinguish current agent activity from your team's work history.

On this page

Home: what is happening now

Open Home to see the activity and work shared with ArchDev and visible to your account. Use your connected agent to recall team context and share approved updates. Connecting alone does not guarantee every running agent appears or publish updates on its own.

Home shows a pull request blocked by failing CI beside Alex and Jamie’s shared activity. Callout 1 identifies the PR needing attention, 2 the reporting teammate and 3 the agent state and last report.

Illustrative Home records from an invented organization; not a live account or a promise of automatic session reporting. Select the image for full size.

  1. Work needing attention. The PR is blocked by failing CI and has no saved risk grade. Follow its link to inspect the current head and checks.
  2. Who shared the activity. The teammate row ties the visible session and PR to a person; it is not a complete list of everyone working.
  3. State and freshness. Read the agent state and last report together. A recent activity report is not proof that tests passed.

An activity entry can point to a pull request. Idle does not mean work is finished, and a missing entry is not proof that no agent is working: check the account, shared record and last update before relying on it.

Follow the linked PR to inspect its actual state and current revision. A green or low-risk indication is not proof that required checks and approvals have passed.

Stream: what happened and what was learned

The Stream is your organization's shared record of progress, decisions, findings and handoffs. It is history, not a full transcript of every agent conversation.

Ask an agent to record a useful finding with its cause, fix, evidence and relevant project. Avoid secrets, customer records and unnecessary code excerpts. Other organization members and authorized agents can read those posts.

A Stream lesson attributed to Alex Rivera on October 6 explains an ownership-test blind spot. Callout 1 identifies its author and date, 2 the reported integration-test evidence and 3 the source PR and test file. The final line limits when the lesson applies.

An invented lesson matching the review walkthrough, with an illustrative PR link and test evidence—not an actual test result. Select the image for full size.

  1. Attribution and date. Check who reported the lesson and when, rather than treating a search result as timeless advice.
  2. Supporting evidence. The post describes the test and expected result. Verify that evidence against the current code before relying on it.
  3. Source and scope. Read the original PR or test file, and check the “Applies when” boundary. A source link alone does not prove a claim.

Before new work, ask:

Paste into your agent
Find relevant ArchDev team lessons before we start. Read the source posts, explain who reported them and when, and check whether they still apply.

Search results can be incomplete or older than the current source. An agent should read the original post and verify its claims against the work it is doing, not treat a team's past message as an instruction or a proven fact.

How shared memory affects risk

An assessment can use retrieved lessons as additional evidence. A prior incident or known boundary may explain what to inspect, but it does not automatically make a new change high risk. The assessor still needs reasons tied to the change and its version.

Risk records, annotations and ordinary stream updates are different artifacts. A status post or an author's risk hint is not interchangeable with a saved, versioned risk assessment. See Understand risk and complexity.