Set up an organization¶
Prepare an Organization so developers can make governed requests and consumers can use shared Agents. This guide is for administrators of an existing deployment; operators should first complete installation and bootstrap.
Prerequisites¶
Have an active Organization membership and authority to perform each setup task. An Organization owner or administrator can perform most setup; scoped administrators should follow the permissions named in each linked guide. Human roles, Team resource allowance and application key policy are separate. Read access concepts before assigning them.
Procedure¶
- Establish people and Teams. Invite people or configure enterprise identity. Create a Team, add memberships and assign scoped roles. Joining the Organization alone does not grant Team or inference access.
- Prepare the catalog. Configure models, native providers, Connectors and tools in reviewed YAML. Validate the configuration and coordinate gateway/Console restart with the operator.
- Allow the intended work. Select the Team's allowed resources and configure budgets. Developers can then issue virtual keys. For backend ownership, create an ordinary service account and service key.
- Verify a first request. Have a developer follow the model quickstart. Check a permitted request and a denied operation, the canonical Request and settled Usage.
- Apply governance. Configure model guardrails, tool rules and administrator approvals. Test the applicable connection flow separately from the permission to invoke a tool.
- Publish managed applications when needed. Have a builder save and test an Agent. Review funding, accounts, Chat audience and API callers, then verify the live version. External SDK code needs no Builder Agent.
- Complete the customer handoff. Use the launch checklist for connection details, role-specific acceptance checks and operator recovery evidence.
What belongs where¶
| Responsibility | Starting point |
|---|---|
| People, membership and role grants | People, Teams, roles reference |
| Model routes and upstream accounts | Models, Connectors |
| Resource access, caps and policy | Team allowance, budgets, guardrails |
| Denied access or containment | Diagnose access, roles and containment |
| Management history | Audit |
| Files, environment and service restarts | Configuration, operator guide |
Expected result¶
Each Team has explicit ownership, resource allowance and limits. Developers have credentials for the intended resources, while Chat consumers have the appropriate audience grant. No reusable provider credential is handed to application users.
Verification¶
Use Observe → Requests for gateway decisions, Traces/Sessions for observations and Usage for physical ledger amounts. Use Audit for administrative changes. Verify metadata, captured content and export under their separate permissions.
Failure recovery¶
Find the exact missing boundary with access diagnosis. A Connector's lost authorization needs its connection recovery, separately from Team or key access. Role, allowance, key policy and budget changes apply at the next current-authority check. YAML, static-secret and service-environment changes require the documented restart. Credential rotation requires clients to reload the new secret.