The Monday question an agency account lead asks
An agency account lead runs eight client projects in Basecamp. On Monday they want three answers. Which deliverables are waiting on client approval? What did each client say in correspondence last week? Where does each card on the status board sit? Basecamp in ChatGPT answers all three from reads. The risk is a different kind of call: a write that a client can see.
Elaichi's basecamp connector carries 104 tools: 58 read, 18 create, 19 update and 9 delete. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves 600+ connectors through one organization endpoint, so Basecamp sits beside the agency's other apps.
For most teams the dangerous Basecamp tools are the ones that trash work. For an agency, the dangerous ones are the ones that talk to clients. A message posted to the wrong board, or one internal thread switched to client-visible, is a client conversation the agency did not mean to have. This playbook keeps every read open and leaves the writes that can reach a client to the people who should make them.
How client visibility works in a Basecamp project
In Basecamp, everything in a client project starts private to the team, and the team chooses what to share item by item (Basecamp help, What clients can see and do, checked October 2026). Basecamp's API reference describes clients as external collaborators who log in to see only what a team chooses to share (Basecamp API, people, checked October 2026).
Visibility is set on some items and inherited by others. The same help page lists both:
| Item | How its client visibility is set |
|---|---|
| Messages on the Message Board | Individually |
| To-do lists | Individually |
| Card tables | Individually |
| Schedule events and check-in questions | Individually |
| Comments | Inherited from the item they are on |
| To-dos | Inherited from their to-do list |
| Cards | Inherited from their card table |
Two consequences matter for an AI client. Once an item is visible to a client, the client also sees all its existing comments. Clients are also notified of future comments, chat lines and check-in answers on anything they can see. A comment is therefore never private on its own. It is exactly as visible as the thing it sits under.
Which Basecamp writes can reach a client
Any write into a project with clients can land where a client reads it, and one tool changes what clients can see at all. These are the writes that touch the items in the table above.
| Tool | How it reaches a client |
|---|---|
update_a_basecamp_client_visibility_by_id |
Sets visible_to_clients on a recording, which shows it to the project's clients or hides it |
create_a_basecamp_message, update_a_basecamp_message_by_id |
A message takes a visible_to_clients argument; a published one notifies everyone on the project when no subscriber list is given |
create_a_basecamp_comment, update_a_basecamp_comment_by_id |
Posts or edits under any recording; on a client-visible item, the client sees it and is notified |
create_a_basecamp_todo_list, create_a_basecamp_todo, update_a_basecamp_todo_by_id |
A to-do inherits its list's visibility, so a to-do added to a client-visible list is visible |
create_a_basecamp_card_table_card, update_a_basecamp_card_table_card_by_id |
A card inherits its card table's visibility |
create_a_basecamp_schedule_entry, update_a_basecamp_schedule_entry_by_id |
Schedule events carry their own visibility setting |
create_a_basecamp_campfire_line |
Clients are notified of chat lines on anything they can see |
Documents, uploads and vaults add content to a project too. Basecamp's help pages cited here do not say how those inherit visibility, so treat create_a_basecamp_document, update_a_basecamp_document_by_id, create_a_basecamp_upload, update_a_basecamp_upload_by_id and create_a_basecamp_vault the same way.
The visibility tool is the sharpest. One call can turn an internal thread, with its whole comment history, into something the client reads. Basecamp's API returns 403 Forbidden when a recording inherits its visibility from a parent (Basecamp API, client visibility, checked October 2026).
create_a_basecamp_message defaults visible_to_clients to false for team callers. That default holds only while nobody sets the argument. A model asked to "post the update for the client" can set it to true.
A to-do or a card write looks internal, but it takes the visibility of the list or table it lands in, and a restriction names tools, not projects. A to-do written into a client-visible list is visible to the client. So the staff role does not get "to-do and card writes" as a safe middle ground.
Holding account staff to the Basecamp reads
Give the account staff role an allow rule that names only the basecamp connector's read tools, and leave every write off it. A restriction in Elaichi is a rule naming which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So the agency needs two roles: one for account staff and one for account leads, who do post to clients.
Three details of an allow rule shape the setup:
- It is the role's whole allowlist. An allow rule naming one tool of a connector admits that connector for that tool only. Once a role carries any allow rule, every connector and tool that none of its allow rules names is restricted, across all connectors.
- Other apps need their own rules. If staff also use Salesforce or Slack, add a whole-connector allow rule for each. Separate allow rules in one layer merge into one allowlist, so one rule per app works.
- A block rule is the wrong shape. A layer with only block rules has no allowlist, so every Basecamp write the rule does not name stays reachable. Naming all 46 non-read tools by hand is easy to get wrong.
The account leads' role carries no allow rule, so it keeps everything. Staff keep all 58 reads, including the client approvals, correspondence and card table reads below. They do not keep follow-up to-dos or card moves through ChatGPT, which stay with leads or in Basecamp itself. A restriction change takes effect within about two minutes.
When an account staff member does need to reply to a client, they file an access request. An admin approves it in the console, under Governance, Access requests. The grant lifts exactly the one tool for that one person, and every other rule on their role keeps applying. No access request can be approved from inside ChatGPT, so no AI session can widen its own reach.
Why not lock visible_to_clients to false with a freeze?
A freeze is the wrong control here, for two reasons. A frozen parameter in Elaichi locks an argument on a toolbox entry, so the model cannot change it. In Elaichi, a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. An agency on per-person Basecamp connections reaches each person's own connection directly, where the tool runs unfrozen.
The second reason is in Basecamp's model. Comments have no visibility argument at all, because they inherit visibility from the item they are on. No frozen value on create_a_basecamp_comment can keep a comment private on a client-visible card. Leaving the tool off the allowlist is the control that holds.
Reading client approvals, correspondence and status cards
The reads an account lead needs are all reachable, and none of them changes what a client sees. Basecamp's Clientside has its own read tools. list_all_basecamp_client_approvals returns each approval with its status and approver. list_all_basecamp_client_correspondences returns client correspondence with its reply count. list_all_basecamp_client_replies reads the replies under one correspondence or approval.
Status boards live in card tables. get_single_basecamp_card_table_by_id returns a table's columns, and list_all_basecamp_card_table_cards reads the cards in one column. list_all_basecamp_projects returns each project the person can see, with its clients_enabled flag. That flag lets the model mark which projects have clients at all before it summarizes anything.
A useful Monday prompt reads like this: list every pending client approval across my projects, then the last client correspondence in each, then any card in the "Waiting on client" column. That is three read paths and no writes. Run it from an account staff login and it works the same as from an account lead's, because every step is a read.
Whose Basecamp account each ChatGPT call runs on
Each person's own. Elaichi's basecamp connector signs in as a person, and every call through a connection uses the account it was connected with. A shared Basecamp connection reaches Basecamp as the person who connected it, for everyone it is shared with. At an agency, that would let a staff member read every client project the account lead is on.
Have each person connect Basecamp in Elaichi with their own Basecamp sign-in, and leave it unshared. Basecamp then decides which client projects each call can read, and Elaichi's role rules decide which tools each call can use. Basecamp's own guide says an app uses Basecamp on the person's behalf through their OAuth 2 token (Basecamp's authentication guide, checked October 2026).
When a client company leaves a project, Basecamp switches every item previously visible to the client back to private (Basecamp help, Working with clients, checked October 2026). Nothing in Elaichi needs to change for that.
Setting up Basecamp in ChatGPT for the agency
A workspace admin publishes Elaichi once as a custom app. OpenAI says full MCP support, including write actions, is rolling out in beta to ChatGPT Business, Enterprise and Edu (OpenAI help center, checked October 2026). On Business, only admins and owners enable developer mode and deploy an app. The path is Workspace settings, Apps, Create. Enter https://api.elaichi.ai/mcp exactly, click Scan Tools, then Create, and publish the draft.
ChatGPT's own action settings sit on that one app, not on Basecamp's tools behind it. In Elaichi, connected tools are never listed one by one, however few there are. The model finds Basecamp tools with search_tools and runs them through execute_tool. A ChatGPT setting can gate that one tool, but it cannot single out the visibility tool from a read. The per-tool decision lives in Elaichi's restriction. The full setup is in connecting Elaichi to ChatGPT.
On Elaichi's consent screen, "Run your connected tools" covers a connected app's reads and writes alike. Leaving a box unticked does not make Basecamp read-only, and it does not keep a comment away from a client. The allow rule does.
Basecamp's hosted server versus a control plane for an agency
Basecamp hosts its own MCP server at https://mcp.basecamp.com/mcp, included with every Basecamp account (basecamp.com/ai, checked October 2026). Basecamp's page says the assistant acts as the signed-in person. On approval, each person picks Read-only access or Full access. For an agency that needs only Basecamp, with staff on read-only and leads on full access, that is the simpler setup with no second vendor.
Elaichi's case is narrower and specific:
- Per-tool rules on a role. Account staff hold the Basecamp reads while every write stays restricted, and the leads' role keeps them.
- One address across apps. The same endpoint serves Basecamp and the agency's other apps, in ChatGPT, Claude and Cursor.
- One audit trail. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), whichever app the call reached.
Each entry names the person, the Basecamp connection reached, the tool and the outcome. It logs the one path argument that names the object, as the target id, and nothing else about the arguments, so a comment write shows which recording it went under. ChatGPT is named as the client. Read the Basecamp writes weekly, and check that each one landed in a project you expected. The same per-person pattern for an internal project team is in Basecamp in Claude for overdue to-dos. Client-facing work in a CRM follows a similar shape in Salesforce in ChatGPT for a sales team, and every other app is in the connector catalog.
