Recover the tradeoff
Find why a decision made sense then.
Them AI for Engineering
Keep the reasoning behind the system
The code shows what exists. It rarely explains every tradeoff that made it that way. Bring architecture decisions, reviewed incident lessons, and onboarding guidance into shared rooms where teammates can inspect the sources behind answers.
Mac-only for now. Free during the beta (invite-only).
Engineering roomShared room
You with your team
Why is this work handled asynchronously?
Them AI with company contextThis job runs outside the request path because completion can be delayed and retried. An immediate response requirement would change the assumptions recorded in the architecture decision.
↗ Example architecture noteReview with Service owner
After human approvalAsynchronous processing decision
A useful record for the next person.
Illustrative workflow. Not a live conversation.
The work gets better when the context stays.
Good judgment belongs
with the whole team.
Share operational lessons
Keep reviewed incident learning available beyond responders.
Ground agent context
Retrieve approved knowledge through the MCP interface.
In the day-to-day
Work your team can bring to Them AI.
Start with the question. Keep the source. Make a person responsible for what comes next.
Engineering room Example 01
Does this decision still apply?
The design assumes independent jobs and recoverable failures. The new dependency needs an immediate result, so that assumption no longer holds. Bring the changed constraint into design review.
↗ Example design decisionArchitecture context
Ask about a design choice with the original rationale in reach. Keep constraints and rejected options visible, then check with the responsible engineer before carrying an older decision into new work.
See how the workflow fits
- Bring
- Decision note
- Review
- Service owner
- Keep
- Design context
Engineering room Example 02
What should we learn from this incident?
The incident review found that recovery depended on an assumption the team had not tested. Preserve the verified contributing factor, then add that recovery condition to the review checklist.
↗ Example incident reviewIncident learning
Keep the lesson after an incident separate from the rush of response. Review a sanitized account of contributing factors and followup reasoning, then preserve the guidance another engineer can use.
See how the workflow fits
- Bring
- Sanitized incident review
- Review
- Incident owner
- Keep
- Reviewed lesson
Engineering room Example 03
Where should I begin understanding this service?
Start with the service boundary, then read the decision rationale and recovery guide. Those sources explain what the service owns, why it exists, and which failures its owner expects.
↗ Example service overviewTechnical onboarding
Give new teammates a way to ask why the system works as it does. Cite approved architecture and operating guidance, then direct unresolved questions to the person responsible for the area.
See how the workflow fits
- Bring
- Architecture overview
- Review
- Engineering mentor
- Keep
- Learning path
Engineering room Example 04
Which checks matter for this change?
Review compatibility, failure handling, and recovery before implementation. The change checklist asks which assumptions have changed and how the developer will validate the affected behavior in the development environment.
↗ Example change checklistChange review
Make your review questions reusable across people and external coding agents. Retrieve an approved skill through MCP, then apply its checks in the development environment where the actual work happens.
See how the workflow fits
- Bring
- Review guidance
- Review
- Maintainer
- Keep
- Review questions
These are example workflows to evaluate, not customer results. Connected agents use their own tools; Them AI is the shared context and review workspace.
From useful work to reusable knowledge
The conversation is
only the beginning.
Memory keeps the facts and decisions. Skills keep a way of working. People decide what deserves to become a shared reference.
Meet Rooms and the Collective- 01
Bring the context
Example architecture note
- 02
Make the human call
Service owner reviews the sources and proposed record.
- 03
Keep the method
Design review
Make it real
Choose a decision people keep questioning
Bring its rationale, its constraints, and an engineer who can explain what changed.
Discuss a design partnership
Before you begin
A few things
worth knowing.
Does Them AI run or deploy code?
No. External coding agents own execution. Them AI supplies shared knowledge and skills through MCP.
Can we put secrets in rooms?
No. Human access is organization-wide today. Use approved technical guidance without credentials, sensitive logs, or restricted source material.
What can we pilot today?
Mac-only for now. Free during the beta (invite-only). Start with reviewed architecture notes and their owners.
What does the current beta include?
Shared rooms, memory with sources and review status, reusable skills, and MCP access for connected agents. Mac-only for now. Free during the beta (invite-only). Human room and memory access is organization-wide. Client-scoped MCP feeds restrict agent retrieval to that client's approved records plus approved firm-wide material. Do not treat a room as a private boundary for individual members. Read the access boundaries.
Bring one real workflow
Make the next project
better informed than the last.
Start with a question your team keeps answering. Bring the sources, the people who know, and the decisions worth keeping.
Mac-only for now. Free during the beta (invite-only).