This page documents how PLRX builds — the protocols we use, the engineering standards every AI agent is held to, and the architecture that makes 94% autonomous operation possible. The platform is built on open standards: A2A for agent coordination and MCP for AI client integration. No proprietary SDKs. No black boxes. The engineering is transparent because that is how trust is earned in regulated industries.
Every PLRX deployment runs the same four-layer architecture. Each layer communicates via open protocols — no proprietary SDKs, no black boxes. The orchestrator is the connective tissue: it receives missions from above via MCP and coordinates specialists below via A2A, while simultaneously reaching outward to any enterprise system that ships an MCP server.
tools/list, invokes them via tools/call. No PLRX SDK required.Mission state is persisted by the Durable State Machine — not in volatile memory. When an agent pauses to wait for a provider document, a payer callback, or a fulfilment confirmation, its workflow suspends durably. Hours later, days later, weeks later, it resumes exactly where it stopped. Crashes replay deterministically. Network failures retry with strict idempotency keys. No state is ever lost.
Every state transition is an event, not a flag. Each step in the workflow — validation, document collection, payer eligibility, prior auth, submission — is a discrete, named state persisted to an append-only event log. The full history of every mission is queryable and auditable at any point in time.
Wait states are first-class. When a mission reaches input_required — waiting for a provider to return a document, or a payer to respond to a prior auth — the workflow suspends without holding a thread or a polling process. It resumes automatically when the expected input arrives. There is no timeout. The mission waits as long as necessary.
The state machine shown reflects the real production workflow — every state and transition taken directly from live execution. No abstractions.
A2A is the open JSON-RPC 2.0 protocol PLRX uses for machine-to-machine task delegation between agents. Every PLRX specialist agent is a fully compliant A2A server. The orchestrator agent delegates to specialists via A2A — clinical documentation, billing, ML scoring — each running as an independent agent, each coordinating through the same open protocol.
Agent discovery via Agent Card. Every A2A-compliant agent publishes a machine-readable manifest at /.well-known/agent.json — its name, endpoint URL, declared skills, and authentication requirements. Your client discovers the agent's capabilities before establishing contact. No out-of-band configuration required.
Tasks follow a durable lifecycle. A task submitted to a PLRX agent via message/send moves through a defined lifecycle: submitted → working → input_required → completed. Each transition is durable — persisted by the PLRX Durable State Machine. A task that enters input_required suspends without losing context. tasks/resubscribe allows your client to re-attach to a long-running task and receive streaming status updates.
Idempotency keys prevent duplicate side effects. Every task submission includes a deterministic idempotency key. If your client retries a failed submission, the platform recognizes the key and returns the existing task state without executing the operation twice. No duplicate emails. No duplicate API calls.
The PLRX platform exposes every mission type as a typed tool through the PLRX MCP Server. Any MCP-compatible AI client — Claude Code, ChatGPT, Cursor, OpenCode — can connect to the platform through a single authenticated connection. This is how PLRX integrates with the AI clients our customers already use.
Tool discovery is automatic. On connection, your client calls tools/list and receives a manifest of every mission type available to your tenant — the tool name, parameter schema, and description. New agent workflows deployed to your tenant appear in the manifest on the next connection without any client-side change.
Missions are invoked as tool calls. A single tools/call triggers the full agent fleet behind that mission type — orchestrator starts, specialists delegate, PLRX Durable State Machine persists state. The server responds immediately with a run ID. Mission progress streams back to the client as state transition events via Streamable HTTP.
Authentication is OAuth2. Every MCP connection is authenticated via bearer token. Tool visibility is scoped to your tenant — your client sees only the missions it is authorized to invoke. Every tool call is logged to the WORM audit trail with caller identity, timestamp, and full parameter payload.
There is no proprietary SDK. The MCP spec is the only contract. This is by design — open protocols reduce integration friction and eliminate lock-in.
The orchestrator connects in both directions. Inbound, it acts as an MCP server — exposing available missions as typed tools to any MCP client above. Outbound, it acts as an MCP client — connecting to enterprise systems that publish their own MCP servers. The same protocol that lets Claude Code invoke a PLRX mission also lets a PLRX agent reach into any enterprise system that ships an MCP server. No custom integration per vendor. No IT project per customer.
Because the orchestrator connects outward via MCP, PLRX agents can reach any enterprise system that hosts an MCP server. They utilize the exact same open protocol, authentication model, and tool-discovery pattern across every single connection.
No Custom Vendor Integrations. Every system within the growing MCP ecosystem is reachable out of the box. As more vendors adopt and publish MCP servers, your connectivity surface expands seamlessly without requiring any code changes to the PLRX platform.
Cross-Fleet Agent Delegation. PLRX agents are never isolated. Via MCP, they can securely connect and delegate tasks to third-party, non-PLRX agents that expose an MCP server — enabling complex, multi-vendor agentic workflows without proprietary bridges.
Every PLRX specialist agent in production is built from the same internal scaffold — no exceptions. A layered architecture with the OpenAPI spec as the source of truth, a full A2A compliance layer, deterministic idempotency on every side-effecting activity, and a three-level test pyramid enforced by the CI/CD pipeline.
The scaffold enforces constraints that are easy to get wrong when starting from scratch — structured error responses on all endpoints, PHI protection enforced at every layer. These are not style preferences. They are correctness requirements for production-grade agentic software.
The A2A compliance layer is zero-configuration. The Agent Card endpoint auto-generates from the skill registry. The JSON-RPC 2.0 dispatch router handles all four A2A methods. Task lifecycle transitions are automatically correlated to PLRX Durable State Machine workflow instances. A new skill registered in the skill registry appears in the card, the router, and the OpenAPI spec without code duplication.
The performance SLA is enforced in CI. All synchronous agent endpoints must respond at P99 < 100ms. This assertion runs as part of the integration test suite on every build and blocks deployment if it fails. The SLA is a delivery requirement, not a target.
The engineering standards that govern every agent we build are published on GitHub — coding guidelines, PR automation, security scanning, CI/CD pipeline patterns, and testing frameworks.
Every protocol PLRX uses is an open standard. No proprietary formats. No vendor-specific abstractions. Full interoperability by design.
Machine-to-machine task delegation between agents. Every PLRX agent is a compliant A2A server and client.
AI client integration. Enables tool discovery, invocation, resource reading, and streaming responses from the PLRX MCP Server.
All PLRX API endpoints return structured error responses on error — structured, machine-readable, and consistent across every agent.
PLRX synchronous API endpoints carry a hard P99 < 100ms SLA. This is not a documentation target — it is asserted in the integration test suite and blocks deployment if violated. The table below lists the SLA for each endpoint category.
| Endpoint type | SLA | Alert threshold | Notes |
|---|
PLRX runs Enterprise AI Agents — persistent, stateful, and infrastructure-hosted. Not session-based assistants running on someone's device. Not tools that stop when a laptop closes. Agents that run continuously on dedicated infrastructure, coordinate across external parties, and log every decision to immutable storage.
PLRX publishes engineering practices, tooling configurations, and developer workflow patterns. The execution engine, agent scaffolding, MCP server, and PLRX Durable State Machine are purpose-built by PLRX — not assembled from generic components. That depth of ownership is what allows PLRX to stand behind every mission with outcome-based pricing.
These resources are not educational examples. They are the actual configurations and standards we apply to every agent we ship.
The Java coding standards applied to every PLRX agent — immutability rules, Optional usage, stream patterns, exception handling, logging conventions, and the specific constructs that are banned and why.
javastandardsproductionThe automated pull request review workflow — static analysis configurations, review checklists, coverage gate enforcement, and the CI hooks that run before a PR can be merged.
ci/cdautomationqualityThe security scanning configurations applied to every PLRX service — dependency vulnerability scanning, SAST rules, secret detection patterns, and the build-breaking thresholds for each finding severity.
securityscanningsastThe reusable CI/CD workflow patterns used across all PLRX service repositories — build, test, image build with semantic versioning, push to artifact registry, and Kubernetes deployment.
ci/cdkubernetesThe three-level test pyramid configurations — unit test patterns with strict mock boundaries, BDD scenarios with real infrastructure containers, and integration test patterns with contract mocks and P99 SLA assertions.
unit testsbddThe OpenAPI-first design workflow used across all PLRX services — spec-first process, code generation configuration, naming conventions, error response patterns via structured error responses, and the SLA contract documentation standard.
openapiapi-firstrfc-7807Request access to connect your AI client, integrate your systems, or deploy a specialist agent fleet on the PLRX Agentic Execution Platform.
The engineering team handles onboarding directly. No automated sales funnel.