> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/platform-overview/cloud-ownership.md).

# Cloud Ownership and Integration Boundaries

Separate software ownership, cloud execution, data storage, operating access, and billing when reviewing a customer-owned agent integration.

An enterprise team may want to own its agent framework, models, evaluations, and releases while using the Concurrence platform for agreed workflow and channel capabilities. Review that division component by component. Buying software and choosing where it runs are separate decisions.

The [reference deployment](/platform-overview/reference-deployment.md) follows a customer application calling a Concurrence-managed agent. Running a customer-owned agent that calls selected Concurrence capabilities introduces a different integration boundary. Use this page to review that proposed arrangement. Customer-account installation, a new warehouse adapter, and an external-agent adapter each need explicit scope and [availability confirmation](/platform-overview/capability-availability.md).

## Make Cloud Ownership Specific

For each component, record these five decisions independently:

| Decision                      | What to specify                                                                                    |
| ----------------------------- | -------------------------------------------------------------------------------------------------- |
| Software and change ownership | Who maintains the implementation, owns customer-specific code, and approves releases               |
| Execution boundary            | Cloud account or managed service, region, permitted inference providers, and fallback paths        |
| Data boundary                 | Records read, transmitted, retained, and written back, including intermediate results              |
| Operating access              | Who can inspect production content, change configuration, rotate credentials, and handle incidents |
| Billing boundary              | Who receives each charge, its meter, and whether it is included in another fee                     |

“Runs on AWS,” “runs in our AWS account,” and “is billed through AWS” answer different questions. Private connectivity describes a network path; it does not move a vendor's processing into the customer's account. For managed inference, identify the service's processing boundary and configured routing instead of treating the caller's account as the location of every processor. Review the selected provider's terms, such as [Amazon Bedrock data protection](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html).

An account restriction should cover supporting work as well as the main agent: context preparation, content checks, evaluation, observability, and support access can each introduce another processing path. Label any proposed placement separately from verified deployment evidence.

## Trace Data Beyond the Source Query

Federation can avoid a standing copy of a source dataset while still returning sensitive query results to another system. For example, [Databricks query federation](https://docs.databricks.com/aws/en/query-federation/database-federation) uses both remote and Databricks compute and returns source results to a Databricks executor. Its availability for a database is not evidence that Concurrence supplies that database's integration.

Review one representative record through the query, context assembly, prompt, action, reply, and outcome. Include logs, traces, caches where used, recordings, backups, and diagnostic exports. A patient reference or a short text summary may still be sensitive even when the full source record stays in place. See [Data Residency](/platform-overview/data-residency.md).

For example, suppose a proposed design queries a customer warehouse, returns appointment details to a vendor-hosted service, and sends a text summary back to the customer's agent. The source table stayed in place, but patient data crossed the account boundary and the vendor processed it. If the requirement prohibits that transfer, the team must change the processing placement or agree on a permitted exchange before accepting the design.

Keeping the system of record in an open table format is also a different requirement from using it as the only store. A workflow can need transactional state for pending actions, suppression, and reconciliation. Agree on the purpose, location, retention, and canonical write-back rule for each record class. If auxiliary storage is prohibited, leave the design unresolved until that requirement has a verified implementation.

Patient communications add a delivery boundary. Identify the actual recipient address, content, and attachments that reach a messaging provider or carrier. A requirement that no data leave a cloud account must be reconciled with those transfers before that channel can be included.

## Define the Handoff to a Customer-Owned Agent

Use three contracts to review a proposed integration. Here, an **opportunity** means a candidate for work selected from source data, such as an appointment needing a reminder. These are integration design inputs, not Concurrence resource types or API fields.

| Handoff                          | Minimum information to agree                                                                                                                    | Failure question                                                                                       |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Opportunity to agent             | Stable case and subject references, purpose, necessary context, source timestamps, eligibility evidence, permitted actions, and expiry          | What happens when context is missing or eligibility changes?                                           |
| Agent to action executor         | Case reference, scoped caller identity, exact recipient and requested action, selected channel/use case, and a retry identifier where supported | Which control rechecks current authority, and how is an ambiguous response reconciled before retrying? |
| Delivery or response to workflow | Channel Manager message or call ID, receipt or reply, event time, suppression changes, and the mapping back to the case and session             | How are duplicate, delayed, unmatched, or missing events handled?                                      |

A useful opportunity is not authorization to act. Text can explain the case to an agent; permission enforcement needs an authoritative check outside that text. Define which customer, Concurrence, or downstream control owns each check, then test it on the selected path. Do not assume that one channel's approval or idempotency behavior applies to another.

Consider a reminder selected at 09:00 for an appointment the patient cancels at 09:10. Before the 09:15 send, the action executor needs current appointment and contact-permission evidence. The expected result is to suppress the obsolete reminder and record why. This case tests the source reference, freshness rule, and action check together; a well-written opening message would not resolve the stale-data problem.

If the customer owns the agent runtime, explicitly assign its session state, evaluation cases, tool permissions, releases, and incident response. Separately confirm the Concurrence access contract, channel provisioning, callback authentication, and integration adapter. Product API access, managed provisioning, and an operator UI are distinct deliverables. Use [Channel Program Readiness](/channels/program-readiness.md) to review the delivery side.

## Prove Portability at the Interfaces

Open formats and documented interfaces can reduce migration work, but they do not make every workflow interchangeable. Test whether another component can read representative context, interpret identifiers and provenance, submit an allowed action, and reconcile its outcome. Record the configuration, consent evidence, sender resources, and history that can be exported or transferred, along with any provider or contractual limits.

Finish with named owners, unresolved dependencies, and an explicit decision in the [evaluation packet](/platform-overview/evaluation-packet.md). Keep the [cost and billing review](/platform-overview/cost-and-latency.md#separate-software-operation-and-cloud-charges) alongside the technical boundary so that the same resource is not counted twice.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.concurrence.com/platform-overview/cloud-ownership.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.