OEM & Technology Partnerships
Use Decision Terrain’s OEM integration path to add persistent AI work to your product or customer solution across the systems your customers already use - with supported APIs, scoped authority, human review for covered actions, and evidence for investigation. We are evaluating specific OEM and solution-provider integrations now.
Agent API · webhooks · MCP
Customer-hosted · DT-hosted · air-gapped
OEM and solution-provider paths
01 / Partnership paths
A software vendor embedding DT and a solution provider implementing DT are solving different commercial and operating problems. Start with the role you expect to own.
Keep your application as the place where customers initiate work and use the result. DT can provide persistent agents, connected tools, review points, and execution evidence behind that experience. We scope the API surface, deployment, licensing, branding, and support model around the proposed integration.
Use DT as the agent platform within a broader deployment you design and deliver. Connect customer systems, configure the workflow and controls, and agree which implementation, training, and support responsibilities stay with your team, the customer, or Decision Terrain.
Separate arrangements. OEM embedding, white-label presentation, resale rights, and implementation services are not interchangeable. None is implied by another; we scope only what the proposed customer and integration require.
02 / Integration
Your application can work with a persistent DT agent without treating every assignment as a synchronous request. Configure the responsibility once, then use supported interfaces for each stage of the workflow.
Use the Agent REST API to create or configure an agent, send work, manage files, and inspect its state. An inbound webhook can also trigger a configured agent from an event in your system.
Review Agent API interfacesRead timeline events with durable cursors or wait for newer activity through bounded event requests. Use signed webhook notifications for supported pending-action events, and reconcile current state through the API after delays or retries.
Review events and webhooksList and resolve supported human-input and approval requests from an interface you build. Retrieve resulting files and available outputs, then return them to the product or customer workflow where they belong.
Review decisions and resultsAccepted is not complete. Follow the timeline and the relevant operation result before presenting an outcome as final. Examine the developer interfaces.
03 / Control
The useful question is not whether an agent is autonomous. It is which identity can start work, which systems and operations are available, where policy applies, and which decisions require a person.
Scoped API keys separate read, operate, and manage access. Requests remain subject to the acting user or organization’s permissions, agent ownership, connected-account scope, and the deployment’s network rules.
Review scoped API accessWhere enabled, Organization security rules can monitor or block selected outgoing content, destinations, tool arguments, incoming messages, and returned results. Coverage depends on the configured rule, integration, and execution path.
Review the control modelSupported OpenAPI operations can be read-only, autonomous writes, or approval-required. An authorized reviewer can inspect the proposed operation and arguments. Approval applies to that request; other tools and channels need their own control review.
Review operation classesAn authorized integration can request a cooperative stop for current agent work or deactivate the agent to prevent normal processing. A stop may not cancel work already accepted by an external system, and neither control reverses completed actions.
Review operating practiceReview the applicable identity, approval, policy, and evidence boundaries inSecurity & Governance.
04 / Evidence
An activity count or chat transcript is not enough for a consequential workflow. Within the coverage, permissions, capture, and retention actually enabled, DT records can help an authorized reviewer reconstruct the path from initiation through response.
The recorded person, system, event, or trigger, when known.
The agent, account, credential context, operation policy, and applicable decision.
The recorded tool, operation, provider, destination, or counterparty within the covered path.
The attempt, dispatch state, platform-observed result, error, or unresolved gap.
The policy decision, access or configuration change, or other captured intervention - with its coverage limit.
Different records answer different questions. Administrative security activity, Agent Audit View, the work timeline, and external-provider logs are not interchangeable. No single source is a universal record of every action.
A recorded success has a boundary. A DT-observed result is not independent proof of downstream delivery or business completion. An authority label alone also does not prove that an external action was properly authorized.
Telemetry is configurable. Selected agent-audit summaries and metadata can be forwarded to a configured OpenTelemetry HTTP log collector. This is not a prebuilt connector to every SIEM, every audit ledger, or full evidence.
05 / Deployment and embedding
Hosting the platform, placing inference and tools, and presenting the customer experience are related decisions, but they are not the same decision.
Place the application, state, workers, storage, and configured execution services in the customer’s environment. Production sizing, hardening, networking, upgrades, monitoring, backup, and recovery are part of the deployment scope.
Review customer-hosted scopeRun the platform, model inference, and required workflow tools inside an isolated boundary. External SaaS dependencies are replaced with internal alternatives or left disabled, and the disconnected operating lifecycle must be planned and tested.
Review air-gapped deploymentHave DT operate the platform under an agreed hosting and support scope. Infrastructure location, connectivity, enabled features, data handling, and operating responsibilities are confirmed for the proposed integration.
Review DT-hosted scope06 / Technical evaluation
A useful first engagement is small enough to evaluate and important enough to expose real integration and control requirements.
Bring the product or customer context, intended users, workflow, required systems, and deployment constraints. Keep the initial inquiry unclassified and non-sensitive.
Identify one workflow, its interfaces, an evaluation owner, consequential actions, agreed success criteria, evidence to inspect, and operating responsibilities to test.
Connect the trigger, progress, decision, and result path. Test the applicable success, denial, approval, failure, retry, stop or pause, and evidence-retrieval cases.
Use the result to decide whether and how to scope licensing, deployment, branding, implementation, and support.
Questions to settle
These answers describe the first conversation - not a standard partner tier, published license, or promise that every capability is enabled everywhere.
No. Decision Terrain is exploring specific OEM and solution-provider integrations. This page is an invitation to evaluate a concrete technical fit, not enrollment in a partner tier, certification, or public partner network.
OEM describes incorporating DT into another offering. White-label concerns branding. Resale concerns commercial distribution rights. Implementation services concern who designs, configures, deploys, and supports a customer solution. They combine only when the parties explicitly scope them together.
DT supports operator-configured forwarding of selected agent-audit summaries and metadata to an OpenTelemetry HTTP log collector. It is not a preconfigured connector to every SIEM and does not send every audit ledger or full evidence. We map the required records, coverage, retention, and collector path during the evaluation.
The Agent API supports requesting a cooperative stop for current work and deactivating an agent to pause normal processing. An external service may finish work it already accepted. These controls do not reverse completed messages, edits, purchases, or other external actions.
Supported SAML 2.0 or OpenID Connect SSO and SCIM provisioning can be configured where enabled. Installation-level product terminology and support details are configurable. The branded experience, identity flow, commercial rights, support path, and responsibility for updates must be agreed for the integration.
No. Availability depends on the deployment, enabled features, permissions, connected services, and configured execution path. The technical evaluation confirms the interfaces, approval points, evidence, and operational controls for the intended customer configuration.
07 / Bring one integration to the table
Tell us the product or customer workflow, the systems involved, the intended deployment, and who would own the evaluation. We will use the first conversation to decide whether a scoped technical evaluation makes sense.