From a Request to a Bounded Team Agent

The team-agent builder in trycompai/crm addresses a harder form of automation than background research. A research agent can stop before it writes an uncertain fact. A team agent can create a CRM task, add a note, or send a Slack message. The practical question is how a natural-language request becomes an explicit, reviewable contract for scope, data, triggers, and actions. The answer is not a more persuasive prompt. It is a chain of inspection, validation, human approval, and run-time enforcement.

The builder starts with what actually exists

Imagine a user asks for an agent that watches a CRM event, reads the relevant record, and tells a team what happened. The request is meaningful, but it is not yet an executable specification. The builder must still know which records the agent may read, which integrations are connected, which event types the CRM supports, where a message can go, and whether the requested action is available.

The builder specialist calls inspect_context first. That context includes connected integrations, tagged CRM records, the current time, supported CRM events, and any existing draft. The specialist does not invent a Slack channel because the user named one. It does not assume that Gmail can send because Gmail history is readable. It does not expand a request about one contact into access to every contact in the workspace.

This inspection-first rule makes the agent’s available world concrete. A user can ask for a CRM note, a CRM task, a run summary, or a Slack message. The builder can draft only the action types the runtime supports. Gmail and Google Calendar are read-only sources when connected. Slack can be an executable destination, but only after the workspace exposes the destination to the builder and the agent pins it in the resulting manifest.

The builder asks a question only when the answer changes the bounded behavior. If a destination cannot be derived from the inspected context, it offers a focused choice among real channels or people. The user does not need to type a Slack ID that the system can inspect. If two people match, the builder presents the ambiguity. If no safe interpretation exists for an essential trigger or action, it pauses rather than saving a draft that hides the missing decision.

This is a different use of conversation from ordinary chat. The conversation is not the permission. It is the place where the request becomes precise enough to validate. The actual permission comes from the resources, connections, triggers, and actions that the system stores after inspection.

Scope is an explicit mode

The builder gives an agent one of two CRM record scopes. SELECTED means the agent can work with exact records tagged in the private builder conversation. WORKSPACE means the user explicitly requested workspace-wide CRM access. An empty selected list never means all records.

The distinction prevents a common failure in natural-language automation. A request such as “keep an eye on this deal” points to one deal. A request such as “find every open deal without recent activity” points to a workspace-wide operation.