How we integrate

One platform, plugged into your systems, running inside your walls.

The reason we recommend one pilot rather than seven projects is that they share a backbone. We build the agent layer, the connectors into your systems, and the human review step once. The harder questions for a research institution are how the agent reaches your data, who controls it, and where it runs. That is what this page answers.

The integration map

Your systems on the left. A managed connector and API layer in the middle. Agents that draft and propose, and people who approve, on the right.

Carnegie systems

Concur

Expense and travel

Salesforce

Contacts and CRM

Marketo

Events and email

Andy intranet

HR and Comms docs

Journal databases

Library accounts

Web and social

Public channels

↔

Managed API and connector layer

Vaulted credentials, scoped access, rate limiting, retries, and full logging. This is the part we manage so you do not have to.

→

Agent layer

Extract, summarize, dedupe, monitor, draft, schedule

Human review

A person approves every post, merge, and send

How we manage the connection to your systems

Reaching Concur or Salesforce safely is not a prompt. It is credential handling, permissions, rate management, and logging. That engineering is what we bring, and what a general assistant does not.

Credential vault

Every system credential and API key is stored in a managed secrets vault. Agents never see raw secrets, and access is scoped per connector and revocable in one place.

Scoped, least-privilege access

Each connector gets only the permissions its use case needs. The Concur agent cannot touch Salesforce, and read-only stays read-only.

Rate limits, retries, and queues

We manage each vendor's API limits, back off and retry cleanly, and queue work so a busy system is never overrun. Your existing integrations are unaffected.

Full observability

Every call an agent makes is logged with who, what, and when. You can see and trace every action, and set alerts on anything unusual.

Security and governance, built for a research institution

We know this is the part that decides the engagement. Here is how the platform respects your data, your identity systems, and your compliance obligations.

Runs in your environment

Deployed inside your cloud tenant or private network, behind your perimeter. Your data does not leave your control.

SSO, SAML, and SCIM

Staff sign in with your existing identity provider. Access is provisioned and de-provisioned through your directory.

Role-based access

Permissions follow your org. A scholar, a coordinator, and an administrator each see and do only what their role allows.

Your data is not used for training

Content processed by the platform is never used to train foundation models. It stays yours.

Immutable audit trail

Every extraction, merge, send, and approval is recorded in an append-only log, ready for review or compliance.

Data residency and retention

You set where data lives and how long it is kept. PII can be redacted or masked before it ever reaches a model.

Why a built platform, and not a chat window

A general assistant is excellent at answering questions. Getting real work done inside Concur, Salesforce, and Andy, safely and on your terms, takes the layer we build around it.

Capability	Your Carnegie platform	A general assistant
Connects to Concur, Salesforce, Marketo, and Andy
Acts with scoped, auditable permissions
Human approval built into every workflow		limited
Runs inside your security perimeter
Tuned to your taxonomy, GL codes, and brand
One platform reused across all seven use cases

The platform uses the same frontier models you already trust. The difference is the governance, the connectors, and the control that sit around them.

We deploy where you already work.

AWS, Azure, or GCP, in your tenant, integrated with your identity provider and your change-management process. Your IT and security teams review the design before a single connector goes live.

See the engagement plan