MyOpsAgent Deployment & Integration Guide

1. Deployment Models

Public Website Agent

Embed the organisation's configured agent on an approved website to answer from public business knowledge and expose only intentionally public actions.

Authenticated Internal Use

Employees or authorised users access a wider organisation context through authenticated MyOpsAgent surfaces. Internal information should not be exposed through the public deployment simply because both use the same conversational experience.

Server Integration

Existing applications can integrate with enabled MyOpsAgent APIs or tools using organisation-scoped server credentials and the contract supplied for that module.

2. Pre-Production Checklist

• Confirm the organisation and environment are correct.
• Confirm the intended audience: public, customer, employee or administrator.
• Review the knowledge sources available to that audience.
• Review enabled tools and whether any of them can change business state.
• Confirm approval requirements for controlled actions.
• Confirm connected systems and which system is authoritative.
• Test error handling, unavailable dependencies and ambiguous requests.

3. Website Deployment

Use the organisation-specific embed configuration supplied by MyOpsAgent. Where domain restrictions are enabled, production and staging domains must be explicitly allowed.

Do not copy server-side credentials into browser code. Only identifiers or credentials specifically intended for browser deployment should be exposed to the client.

4. Server-to-Server Integration

• Store credentials using the host application's secret-management approach.
• Use HTTPS.
• Separate production and non-production credentials.
• Log correlation identifiers needed for troubleshooting.
• Avoid logging sensitive payloads unless required and permitted by your data policy.
• Revoke credentials that are no longer required.

5. Enabling Actions That Change Business State

Treat write-capable tools differently from read-only information retrieval. Before enabling a tool that creates, reschedules, cancels, assigns, approves or otherwise changes business state:

1. define the identities allowed to use it;
2. validate required fields and business rules;
3. define whether approval is required;
4. test duplicate and retry behaviour;
5. record enough information to determine what was executed; and
6. verify the resulting state where the workflow supports verification.

6. Operational Decision Workflows

When the deployment includes the Operations Centre or another controlled decision module, populate and validate the business state before relying on consequence analysis. A deterministic engine can only be as reliable as the governed inputs, rules and constraints supplied to it.

7. Monitoring After Release

• Review failed or ambiguous requests.
• Keep source knowledge current.
• Investigate repeated permission failures rather than broadening access automatically.
• Review write-capable tool activity and approvals.
• Update connected-system mappings when upstream systems change.

8. Internal Platform Deployment Documentation

Infrastructure topology, database credentials, administrative keys, deployment secrets, internal file paths and privileged management endpoints are intentionally excluded from the public documentation portal. Those materials belong in access-controlled engineering documentation.