Who it's for
Built for people holding more than one set of books
Agencies, consultancies, fractional operators, and teams whose internal context must never reach a customer-facing assistant. Different jobs, same problem.
4
situations, one problem
Different jobs, all versions of holding more than one set of books.
01
A marketing or development agency working across several client accounts
The same team moves between client briefs, source material, and assistant conversations throughout the day.
Usually connects
- Slack
- Google Drive
- Asana
- HubSpot
- Fathom
A Tuesday, today
Maya takes over the Harbor & Pine launch after the account lead gets sick the morning of a client call. The approved positioning is buried in a Slack thread, the old version is still in Google Drive, and the task in Asana has no explanation, so she presents a line the client rejected two weeks earlier.
What changes
Client context can be organized with a boundary that matches the account it belongs to.
What they actually ask
- “What did we actually promise Harbor & Pine about the launch date?”
- “Why did the client reject the first homepage direction?”
- “Which feedback from the last call still has not made it into the brief?”
- “Where did this claim about their audience come from?”
The first week
Day 1
Choose one account
Start with an active client whose team already feels the cost of scattered context.
Day 2–3
Connect its working sources
Bring in the approved channels, folders, tasks, and call notes for that account only.
Day 4–5
Test real account questions
Ask about decisions, promises, and open feedback, then check the cited sources before widening access.
Not for you if: If one person handles one client and already keeps all of its context in one place, a personal memory tool is likely enough.
02
A consultancy where partners lead separate engagements
Partners may share a firm, tools, and internal methods while handling work for different engagements.
Usually connects
- Microsoft Teams
- Outlook
- SharePoint / OneDrive
- Salesforce
- Granola
- Jira
A Tuesday, today
Eli is pulled into the Alder Row engagement the night before a steering meeting. He finds a polished recommendation in SharePoint but misses the later meeting note where the client ruled it out, so the team spends the opening minutes explaining why an abandoned idea is back on the agenda.
What changes
Engagement context can be separated from the firm-wide material people choose to share.
What they actually ask
- “What did we tell Alder Row would be in the final recommendation?”
- “Which assumptions did the client challenge in the steering meeting?”
- “Have we solved this problem on another engagement without exposing that client's work?”
- “What is the latest decision on the operating model?”
The first week
Day 1
Set the engagement boundary
Separate one live engagement from the methods and templates the whole firm can use.
Day 2–3
Add the engagement record
Connect its approved email, meeting, document, project, and account sources.
Day 4–5
Run a partner handoff
Have a second partner ask the questions they would need answered before joining the next client meeting.
Not for you if: If every engagement is deliberately open to the whole firm and clients accept that model, a shared knowledge base may be the simpler choice.
03
A company with finance and legal teams alongside customer-facing assistants
Internal teams hold sensitive working context while customer-facing assistants need a narrower set of approved material.
Usually connects
- Microsoft Teams
- SharePoint / OneDrive
- Jira
- Zendesk
- Salesforce
- Google Drive
A Tuesday, today
Nina asks the support assistant how to explain a delayed renewal to a customer. It finds the public policy, but it also pulls language from a finance planning thread about cash flow, leaving Nina to work out which parts can safely go into the reply while the customer waits.
What changes
Internal and customer-facing context can be kept in distinct audience boundaries.
What they actually ask
- “What can the support assistant safely use to answer this customer?”
- “Which approved policy explains why we cannot make that exception?”
- “Did legal approve the wording the customer team is using?”
- “What internal discussion informed this answer, and should it be available here?”
The first week
Day 1
Pick one audience
Define the material a single customer-facing assistant should be able to use.
Day 2–3
Separate approved sources
Connect customer-ready policies and support material without adding finance or legal working discussions.
Day 4–5
Probe the boundary
Ask ordinary customer questions and deliberately sensitive ones, then review the sources used in each response.
Not for you if: If every employee and assistant can appropriately use every piece of company context, one shared workspace will be easier to manage.
04
A fractional CTO or CMO working inside several companies
One operator brings their own working methods to separate companies and uses assistants across those engagements.
Usually connects
- Gmail
- Slack
- Notion
- Linear
- GitHub
- Granola
A Tuesday, today
Jon leaves a product call with Cedar House and joins a roadmap review for Blue Lantern ten minutes later. He remembers that the team rejected a billing rewrite, but not which team, and nearly presents Cedar House's constraint as if it belonged to Blue Lantern.
What changes
Each company's material can live inside its own working boundary.
What they actually ask
- “Why did this team decide not to rebuild the billing flow last quarter?”
- “What did I commit to before the next board update?”
- “Which risks did the founders accept when we chose this plan?”
- “Am I remembering this company's decision, or something from another engagement?”
The first week
Day 1
Start with one company
Choose the engagement with the clearest set of active decisions and recurring questions.
Day 2–3
Connect its decision trail
Add the approved messages, notes, plans, issues, and repository context that explain the work.
Day 4–5
Rehearse a context switch
Ask questions after moving between company spaces and confirm that each answer draws from the intended sources.
Not for you if: If your work is limited to one company or consists only of reusable public methods, separate company boundaries may add more structure than value.
05
A sales team carrying several active accounts at once
Reps move between discovery calls, proposals, and negotiations for different accounts on the same day, and much of what was agreed lives in call recordings and threads rather than in the deal record.
Usually connects
- Salesforce
- HubSpot
- Slack
- Gmail
- Granola
- Fathom
A Tuesday, today
Priya inherits an account two weeks before renewal. The pricing exception the previous rep agreed to is in a call recording nobody transcribed, the thread mentions it in passing, and the deal record says nothing — so she opens the renewal at list price and the customer forwards her the old email.
What changes
Each account keeps its own history of what was asked, promised and agreed, and an assistant answers from that account only.
What they actually ask
- “What discount did we actually agree with this account last quarter?”
- “What objection did they raise on the second call?”
- “Which commitments from the pilot are still open?”
- “Has anyone promised them a custom integration?”
The first week
Day 1
Pick one live deal
Start with an account far enough along that its history is already scattered.
Day 2–3
Bring in its record
Connect the call notes, the email thread, and the opportunity for that account only.
Day 4–5
Ask before the next call
Ask what was promised and what is still open, then check the citations against the recording before trusting it.
Not for you if: If your deals are short, self-serve, and fully captured in the deal record as they happen, your CRM is already doing this job.
06
A development team where agents write code across several products
Decisions get made in pull-request threads, incident channels and design docs, then leave the building — while coding agents start every session knowing none of it.
Usually connects
- GitHub
- Linear
- Jira
- Slack
- Notion
- Confluence
A Tuesday, today
An agent rewrites a queue consumer using the retry pattern the team deliberately dropped after an incident last spring. The reasoning lives in an incident channel and a closed pull request, neither of which the agent could see, so the review catches it on the second pass and the afternoon is gone.
What changes
Each product keeps its own decision record, and the agent working in that repository draws on that record rather than on whatever is in its context window.
What they actually ask
- “Why did we move off that library last year?”
- “What did we decide about retries on this service?”
- “Which approach did we reject in the migration review, and why?”
- “What broke the last time someone changed this?”
The first week
Day 1
Pick one repository
Start with the codebase where onboarding questions come up most often.
Day 2–3
Connect its decision trail
Bring in the pull requests, the issue tracker, and the channel where that team argues things out.
Day 4–5
Ask the questions new joiners ask
Ask why things are the way they are, then follow the citations to check the answer came from a real thread.
Not for you if: If you have one codebase, a small team, and your decisions genuinely live in the repository already, a well-kept docs folder is likely enough.
What people ask before they start
- How long does setup take?
- Start with one team, client, or engagement rather than moving everything at once. Setup is complete enough to evaluate when its approved sources are connected and the people doing the work can test their real questions against the answers and citations.
- Do we have to reorganize our existing work first?
- No. Keep working in the tools your team already uses, choose the sources that belong inside the first boundary, and improve messy folders or channels later if they make answers hard to verify.
- What happens when a client relationship ends?
- Close access to that client space and disconnect its sources according to your contract and retention obligations. The important part is that ending one relationship does not require untangling its material from every other client's context.
- Can one person try it before the rest of the team?
- Yes. One person can begin with a single recurring workflow, test whether the source trail is useful, and document which boundaries the wider team would need before inviting anyone else.
- Do our clients ever see what we connect?
- Connecting client material does not make it client-facing by itself. Your team decides which people and assistants can use each space, and any client-facing workflow should include its own deliberate access and review choices.
Recognize yours?
The free tier is enough to try it against one real client before you decide anything.