Standards & portability
How shared industry protocols and foundation-governed specifications help keep components replaceable.
Keep the value in your business
Entergenie’s approach is to put shared protocols at integration boundaries and keep business-specific capabilities in the systems that own them. Model providers, tool servers, identity providers, and observability backends should be choices your team can revisit.
Use specifications maintained by industry communities and foundations to reduce the amount of platform-specific integration code. Keep the protocol version, transport, authorization flow, and supported capabilities explicit for every connection.
A standard at each boundary
The following standards guide our integration design. Use the checks below to agree compatibility for your deployment and evaluate a replacement.
| Boundary | Standard | Community or foundation |
|---|---|---|
| Tools | MCP | Agentic AI Foundation · Linux Foundation |
| Business APIs | HTTP & OpenAPI | OpenAPI Initiative · Linux Foundation |
| Identity & access | OpenID Connect & OAuth | OpenID Foundation · IETF |
| Observability | OpenTelemetry | Cloud Native Computing Foundation |
| Data contracts | JSON Schema | JSON Schema project |
| Agent collaboration | A2A | Agentic AI Foundation · Linux Foundation |
Tools: MCP
Use MCP for tool discovery, input schemas, and invocation. Keep credentials and resource scope in the connection, with policy enforced before each call.
What this makes replaceable
Reuse tool servers across compatible agent hosts. Keep business capabilities behind a shared protocol.
What to verify
Check protocol version, transport, authorization, input/output schemas, and error behavior against each host. The connection guide includes a runnable MCP server and client.
Business APIs: HTTP & OpenAPI
Describe HTTP APIs with OpenAPI. Put a narrow adapter between an agent tool and the business API; keep business rules and access checks in the system that owns them.
What this makes replaceable
Keep business APIs independent of the agent platform, with contracts your existing tooling can understand.
What to verify
Version the API description and test authentication, validation, pagination, errors, and idempotency. An API description is not a guarantee that two implementations behave identically.
Identity & access: OpenID Connect & OAuth
Use OpenID Connect for user authentication and appropriate OAuth flows for delegated API access. Bind those identities to the Principal, Delegation Grant, and Execution Identity used by the runtime.
What this makes replaceable
Use established identity and authorization interfaces so access stays connected to your organization.
What to verify
Verify issuer, audience, scopes, expiry, and revocation behavior. Authentication alone does not authorize a task, and a provider access token is not the platform’s complete delegation model.
Observability: OpenTelemetry
Use OpenTelemetry instrumentation and OTLP at the telemetry boundary. Correlate task, session, and tool activity with stable identifiers while keeping secrets and sensitive content out of telemetry.
What this makes replaceable
Keep telemetry collection separate from the backend where your team stores and explores it.
What to verify
Check exporter configuration, field mappings, sampling, retention, and access controls when changing backends. Traces help investigation; a durable audit record has separate retention and completeness requirements.
Data contracts: JSON Schema
Use versioned schemas for structured tool inputs, outputs, and exchanged records. Preserve identifiers, timestamps, ownership, and evidence references in portable representations.
What this makes replaceable
Describe and validate inputs and outputs with a contract that can travel with the data.
What to verify
Agree the schema version, field semantics, and migration rules. Verify which records can be exported and restored; portable JSON does not make runtime memory, credentials, or in-flight sessions transferable.
Agent collaboration: A2A
Evaluate A2A for collaboration across separate agent systems. Keep agent-to-agent communication distinct from MCP tool access and from the platform’s internal task and session lifecycle.
What this makes replaceable
Use a common collaboration boundary when independent agent systems need to exchange tasks and results.
What to verify
Confirm supported protocol capabilities and identity mapping with each peer. Exchanging a task does not grant authority; receiving agents still need explicit access and policy checks.
Change models without rewriting business tools
Connect model providers separately from tools and business systems. Keep task objectives, acceptance criteria, policy, and tool contracts outside provider-specific prompts or SDK objects where practical. Use an adapter for the provider’s API and evaluate the replacement against representative tasks.
Model APIs still differ in tool calling, context limits, response formats, safety behavior, and billing. A compatible request shape does not guarantee equivalent results. Review data processing terms and cost before switching, and configure fallback providers explicitly.
Manage configuration in your own workflow
Use the UI, CLI, or Terraform with the same workspace concepts. Keep configuration under version control when reproducibility matters, reference secrets rather than embedding them, and review changes before applying them.
Terraform is a configuration tool rather than an interoperability protocol. HCL files and provider schemas can still contain platform-specific details. Review provider resources, state, and import behavior as part of a migration plan.
Make replacement a reviewable operation
- Record the current protocol versions, capability requirements, authorization, data handling, and cost.
- Run contract tests against the replacement with non-sensitive fixtures, including denied access and failure cases.
- Evaluate representative tasks for quality, tool behavior, evidence, latency, and cost.
- Verify record export, field mappings, retention, and access controls before moving data.
- Roll out within a limited scope, retain a rollback path, and have the responsible owners approve the result.
Standards reduce migration work; business semantics, policy, and quality still need verification. Choose adapters and abstractions for real boundaries, and accept specific dependencies when their benefits justify the switching cost.