Waiting for engine...
Skip to main content

Unify Custom Providers in Agent Control Tower

A global enterprise runs AI agents across three stacks. Their customer-facing chatbot runs on Amazon Bedrock. Their fraud-detection agent runs on an in-house LLM built by the data science team. A third team is piloting agents on a niche provider that Agent Control Tower (ACT) does not natively support yet.

The problem: ACT gives them a single control plane for governance, monitoring, and trust, but only for providers it natively integrates with. Everything else is invisible. Security can not audit it. Leadership can not see it in one catalog. Nobody knows how many agents actually exist across the company.

The Custom Accounts GraphQL API closes that gap. It lets the team register any provider, agent, model, and its governance objects directly through code, so agents that ACT doesn’t natively support still show up in the same catalog, under the same governance, as everything else.

note

These GraphQL APIs are supported on Custom Type provider accounts only. Running them against other provider types may return incomplete or incorrect results because provider-specific fields are missing.

Setting up authentication​

Every request needs a JWT. The flow is two steps.

  1. Generate a JWT — send a GET with Basic Auth. The token is returned in the response.
US: https://api.boomi.com/auth/jwt/generate/{accountID}
GB: https://api.platform.gb.boomi.com/auth/jwt/generate/{accountID}

Username: BOOMI_TOKEN.<your-token-username>
Password: <Boomi_Platform_ApiToken>
  1. Send GraphQL requests with the JWT in the Authorization header:
US: https://platform.boomi.com/graphql
GB: https://api.platform.gb.boomi.com/graphql

Header: Authorization: Bearer <JWT>

Two prerequisites worth flagging before you build:

  • Your Boomi platform account must have the AI_AGENT_REGISTRY feature enabled.
  • JWTs expire every 5 minutes. For any automated flow, generate a fresh token per run (or refresh mid-run for long jobs). Don’t cache and reuse.

Choose your path​

The three paths below are sequential for a first-time onboard, but each stands alone once your catalog exists. Register a provider once, then create agents under it, then layer on governance.

Path 1: Register a provider account (First time onboarding)​

Works best for:
Onboarding a provider ACT doesn’t natively support, an in-house model service, a third-party AI vendor, or a Bedrock/Salesforce account you want represented as a custom container.

Provides you with:

  • A container in ACT that represents your external provider
  • One place to group and organize every agent from that provider
  • No backend enablement or waiting on native integration
  • The account shows up in the ACT UI automatically, so UI and API stay in sync

Example: The data science team registers their in-house LLM service as a custom provider account. It now exists in ACT as a first-class provider, ready to hold agents.

Next step: aiAgentProviderAccountCreate reference

Path 2: Register and version your agents​

Works best for:
Cataloging the actual agents running on that provider so they’re visible, taggable, and governable in ACT.

Provides you with:

  • Each agent registered as a first-class entity in the catalog
  • Automatic DRAFT version on creation
  • Tags and a trust level for categorization and governance filtering
  • Uniqueness enforced per provider account (no duplicate agent names)

Example: The team registers their fraud-detection agent under the in-house provider account, tags it, and marks its trust level for the compliance team to review.

Next step: aiAgentCreate reference

Path 3: Attach governance (Guardrails, Tasks, Tools, LLMs)​

Works best for:
Applying security and compliance.

Provides you with:

  • Guardrails that enforce content filtering and organizational policy
  • Tasks, tools, and LLM records associated to an agent’s DRAFT version
  • Auto-generated external IDs and ENABLED status on creation
  • A full audit trail. Every create, update, and delete is logged for traceability

Example: Security attaches a data-privacy guardrail to the fraud-detection agent so it can’t surface sensitive fields.

Next step: aiAgentGuardrailCreate reference

Verify it worked​

Registration mutations reflect into the ACT UI automatically, but for programmatic confirmation or to power a dashboard, use the query operations. The API exposes 19 queries alongside its 28 mutations, covering provider accounts, agents, and their governance objects.

Query your newly registered agents to confirm the catalog matches reality.

Next step: Queries reference

The Unified Catalog Approach​

The real payoff isn’t any single operation, it’s what the catalog looks like once you’ve onboarded everything:

  • Provider Accounts represent every source: Bedrock, your in-house LLM, third-party vendors.
  • Agents and versions give you a consistent lifecycle model across providers that otherwise share nothing.
  • Guardrails, tasks, and tools apply governance uniformly, so a compliance policy means the same thing whether an agent runs on Bedrock or in your own datacenter.
  • Audit logging on every mutation gives security and governance teams one traceable record.

Automating it (CI/CD)​

Because everything is a mutation, provider and agent registration can live in a pipeline. Treat your AI catalog like code by defining provider accounts and agents in version-controlled files, and have your pipeline call the GraphQL endpoint on merge to keep ACT in sync as teams spin up new agents.

Two hard constraints to design around:

  • JWT expiry (5 min): generate a fresh token inside each pipeline run.
  • Rate limits: the API returns 429 under request spikes. Add backoff/retry rather than firing bulk registrations in a tight loop.

Next Steps​

On this Page