Brief yourself on an account from every past conversation

Brief yourself on an account from every past conversation

Pulls an account's people, meeting history, open commitments and topic timelines from Bridge into one brief with risks and next moves.

Set up the tools below, then run the steps in order for the user, carrying each step's results into the next. The run is done when the user has the outcome below.

Outcome

• An account brief: who you know there and their roles, how the relationship has gone, and what each side still owes.
• How each topic you track has moved across meetings, with what was decided.
• The deal or renewal risks found, each with the meeting it came from and a suggested next move.

Inputs

Ask the user for these before you start.

• account: the company, by name or domain, e.g. acme.com
• topics: what to trace across meetings, e.g. pricing, security review, rollout
• lookback_days: how far back to read, e.g. 180

Set up

Bridge (tool:bridge/search-companies, tool:bridge/get-company, tool:bridge/get-person, tool:bridge/search-meetings, tool:bridge/get-topic-timeline, tool:bridge/search-action-items)

Use the MCP server. Add it to your agent's MCP settings, then sign in when asked.

{ "mcpServers": { "bridge": { "url": "https://api.meetonbridge.com/mcp" } } }

• Search companies: call the MCP tool search_companies
• Get a company: call the MCP tool get_company
• Get a person: call the MCP tool get_person
• Search meetings: call the MCP tool search_meetings
• Get a topic timeline: call the MCP tool get_topic_timeline
• Search action items: call the MCP tool search_action_items

Note: Needs a paid Bridge plan (Professional or above); not on the free Starter plan or a trial. At sign-in the user grants read, or read and write, access. Call get_bridge_context first for the tools the plan and connection allow.

Notes:

• Search meetings: Omit query to browse by date or participant. Pass a returned recapId to get_meeting_details for the full meeting.
• Search action items: Defaults to items assigned to the user (scope: mine) and to explicit ones only; pass scope: all and add created to types to include items added with create_action_item.

Before step 1, confirm access with the cheapest read-only call, like a list or a search. Never send or change anything to test access.

Steps

1. Find the account with Search companies (Bridge). Match account and confirm it with the user if several match. Keep the company's id. If Bridge has no record of it yet, skip steps 2 and 3 and use the people from step 4.
2. Read the account with Get a company (Bridge). Keep its summary, industry, the user's notes and the people Bridge knows there.
3. Map the people with Get a person (Bridge). For each person at the account, keep their title, the user's notes, how many meetings they joined and when they last met.
4. Find the meetings with Search meetings (Bridge). Search the last lookback_days days for account and its people's names. Keep each meeting's recapId, title, date and the participants outside your company.
5. Trace each topic with Get a topic timeline (Bridge). For each of topics, filtered on the names of the account's people from steps 3 and 4, keep the meetings in order with what was said first, what changed and what was decided. Drop moments that are not about the account.
6. List open commitments with Search action items (Bridge). Search open action items from the last lookback_days days with scope all and types explicit and created, and keep those that mention the account or its people. Keep each item, its owner and its meeting.
7. Write the brief yourself. Combine steps 2 to 6 into a one-page brief: stakeholders and their stance, relationship history, open commitments by side, topic timelines, risks (a champion gone quiet, a slipped commitment, a competitor named) and three next moves.

Notes

Bridge only knows the meetings it recorded or joined, so a quiet account may simply meet elsewhere. To put the brief in front of the next meeting, append its summary to that meeting's Notepad with bridge/update-meeting-notepad.

Rules

• Use only the services set up above. The read-only calls they need, like listing ids or polling for results, are fine.
• Ask the user before anything that sends messages, costs money, or changes data, and say how many records it touches. One approval covers a batch the user has seen.
• Never print API keys.