Live, invite-led developer access · Request access
Skip to content

Building client products ​

Keep your product's brand, sign-in, and customer relationship. Start by defining a customer workspace: the users, information, and tools an agent may use for that customer's task.

Design the workspace boundary ​

Map each customer to a distinct workspace in your integration design. Confirm the actual workspace provisioning and isolation behavior during onboarding. A workspace label alone does not establish runtime or storage isolation.

Your backend should derive customer and user identity from an authenticated session, check access to each business record, and permit only the tools needed for the workflow. Do not accept a client-supplied customer identifier as proof of authorization.

Make outcomes visible ​

Show users when work is in progress, when a draft needs approval, and when an operation fails or has an uncertain result. Show completion only after the destination confirms the write. Keep denied approvals from dispatching actions.

Agree on the integration surface ​

Use the connection instructions supplied for your approved environment. The legacy resource model is useful design context, but its HTTP schema is a proposed contract reference. It does not establish the IDs or operations of your live integration.

Build the support request workflow as the first bounded example, with the data boundary documented alongside it.

Your product. Powered by private agents.