Deployment decision memo
Decide the boundaries before choosing a private deployment
Private deployment starts with a concrete question: which information, access, or operating responsibility needs a different boundary? SmaugBrain already connects accounts, plans and owned Agents to a configured runtime. Use this memo to separate that existing control surface from the infrastructure and operating arrangements a private rollout still needs.
On this page
Existing controls and the decisions beside them
Use the current system as the starting inventory, then record the remaining deployment question.
| Surface | Current capability | Question to resolve |
|---|---|---|
| Accounts and plans | Sign-in, plan validity and Agent quantity limits. | Who owns the account and authorizes capacity changes? |
| Agent management | User-owned records, creation, pause, resume, deletion and recovery states. | Who operates the runtime and handles an uncertain operation? |
| Agent launch | Ownership or administrator checks, readiness and plan-expiry checks, then an encrypted launch ticket. | Who controls console access and the surrounding network? |
| Models and profiles | Administrator configuration for provider endpoints, models and Agent instructions. | Where do model requests go, and who may change that route? |
| Token statistics | Account-linked Gateway usage with time-range and model views. | Which additional records are needed for incident investigation? |
Draw the data path across components
Trace the account and plan records in WordPress, the Agent record and runtime configuration, the configured orchestration connection, and the runtime console. Add the chosen model endpoint. List any prompts, files and logs that the intended runtime will create or forward, together with the operators able to inspect them.
An Agent belonging to one account establishes an application ownership boundary. It does not by itself establish a dedicated host, private network or storage region. Hosting the runtime on a separate server also leaves a model-provider data path to review. Record each boundary explicitly.
Assign operating responsibilities
Write a person or team beside each decision before approving a rollout.
Infrastructure
Name the host operator, region, network-access policy and patching owner.
Credentials and models
Identify who provisions credentials, changes endpoints and handles rotation or revocation.
Access and decisions
Separate account administration from Agent instructions. Name the reviewers for publishing, customer-data access and production changes.
Support and recovery
Assign incident triage, escalation, retention decisions and any agreed backup and recovery rehearsal.
Accept the pilot through observable checks
Use synthetic or approved public material before introducing live customer information.
Ownership
Confirm an ordinary account cannot list or launch another account’s Agent.
Plan boundary
Check the agreed Agent limit and the launch response to an inactive or expired plan.
Lifecycle
Create one pilot Agent, pause and resume it, and record confirmed states. Reconcile uncertainty before repeating a remote action.
Configuration
Verify the intended endpoint, model and instructions in the target runtime. A saved browser-model setting still requires its separate runtime synchronization.
Usage
If an approved model request is in scope, check its account usage view and the selected range. Record unavailable statistics as unresolved evidence.
Exit
Agree how access is withdrawn and pilot material is removed. Treat host, runtime and provider records as separate cleanup responsibilities.
A decision record, not a deployment promise
Keep the outcome specific enough for the next reviewer to act on.
Decision: pilot only, no production customer records. Required boundary: approved runtime host and model endpoint. Existing controls to test: account ownership, plan limit, lifecycle, launch, usage view. Unresolved: network policy, credential rotation owner, recovery procedure. Approval: named business and technical reviewers. Next decision: proceed, narrow the scope, or defer until evidence is available.
Scope additional infrastructure separately
Dedicated servers, regional or network isolation, enterprise SSO, SIEM integration, contractual SLA commitments, and backup or disaster-recovery arrangements require a separate design, delivery scope and acceptance evidence. The current provider settings do not establish these arrangements.
Agent profiles are instructions, not an enterprise permission system. Token totals are usage observations, not a complete audit trail or a service guarantee. Carry unresolved conditions into the decision record rather than treating a working launch as proof that the whole deployment is ready.
Deployment questions before approval
Does changing the runtime address create a private deployment?
It changes a connection setting. Server ownership, network restrictions, model routing and operating responsibilities still need to be designed and verified.
Can we begin without moving customer records?
Yes. Define a pilot using synthetic or approved public material. Agree any later access to storefront or customer information separately.
Bring a deployment boundary to review
Share the information involved, intended host and model route, responsible operators and required pilot evidence. We can use those inputs to scope the next technical discussion.
Discuss deployment scope