Opsentry is built for IT teams that need automation to move quickly without blurring customer boundaries. A managed service provider, private equity operating team, or internal platform group might support many businesses, but each business still needs its own ServiceNow queues, Microsoft tenant, knowledge sources, approval rules, audit trail, and runtime configuration.
That is why Opsentry treats a customer as a complete operating instance, not just a label on a ticket.
The client boundary
Every Opsentry runtime starts with a client context. That context includes the client identifier, environment, primary domain, Microsoft tenant, ServiceNow scope, policy pack, SSO settings, and regional deployment preferences.
When Lex receives a request, the API stamps downstream work with that client context. When a worker receives a message, it checks that the message belongs to the same configured client before doing anything. If a message does not match, the worker stops instead of processing another client’s work.
This gives each customer a clean operational lane:
- ServiceNow requests stay tied to the right instance and assignment groups.
- Microsoft 365 actions run against the right tenant.
- Knowledge retrieval can be scoped to customer-specific runbooks and KBs.
- Automation runs carry enough metadata to be audited later.
- Deployment configuration can differ by region, domain, SSO provider, and policy pack.
Why this matters for scheduled work
Scheduled automations are powerful because they remove repetitive admin work. They are also the place where boundaries matter most.
An hourly automation might reconcile a distribution group, scan SharePoint sharing posture, inspect risky sign-ins, or review stale approvals. Those tasks should never rely on an operator remembering which customer they are working inside. The runtime should already know.
Opsentry’s automation flow is designed around that assumption:
- The API saves the automation under the configured client.
- The scheduler wakes up and dispatches due automation runs.
- The worker validates the client context on the message.
- Lex executes the approved tools for that customer’s environment.
- The run summary and trace are written back for review.
The result is repeatable admin work that still has a clear customer boundary.
What changes for onboarding a new customer
When a new customer joins Opsentry, the goal is not to fork the product. The goal is to deploy the same application into a new, isolated operating shape.
For a customer like Kalmadi Capital, onboarding should look like this:
- Create a client environment configuration with Kalmadi’s slug, display name, region, Microsoft tenant, allowed email domains, SSO metadata, ServiceNow instance, and knowledge sources.
- Provision or select the infrastructure boundary for that customer.
- Deploy the shared Opsentry API and worker images with Kalmadi-specific environment variables.
- Connect Lex to Kalmadi’s approved Microsoft 365 and ServiceNow permissions.
- Run smoke tests for chat, scheduled automations, ServiceNow reads, Exchange, Teams, SharePoint, Purview, Defender, and audit trails.
The product stays shared. The runtime context, data, integrations, and permissions stay isolated.
The operating model
Opsentry’s long-term goal is simple: give IT operators an agent that can reason through the work, ask for approval when needed, execute safely, and verify the result.
Client isolation is what makes that model viable in real deployments. It lets Lex become more capable without becoming loose. It gives scheduled automations room to do real work without turning into a cross-tenant risk. And it gives each customer a path to use the same Opsentry platform with their own policies, systems, and business context.
That is the shape we are building toward: one Opsentry platform, many cleanly separated operating instances.