In the first post of the PDIQ Insider blog series, we explored how AI capabilities operate within the same identity, governance, and workflow framework as the rest of the platform. This post dives deeper into the architecture beneath that experience.
At its core, PDIQ is built around three major layers:
- A data layer that provides access to operational and analytical data
- A model layer that supports AI capabilities and retrieval
- An orchestration layer that coordinates workflows, agents, and platform services
These layers share common identity, governance, and access controls, allowing analytics, workflows, and AI capabilities to operate within the same underlying systems.
1. The data layer
Operational data rarely resides in one place. In most organizations, information is spread across POS systems, enterprise back-office platforms, loyalty systems, logistics applications, pricing engines, customer databases, and third-party services. PDIQ works across this entire landscape to ingest, store, and query data.
Data ingestion
Data enters the platform through several supported patterns, including:
- Database connections (JDBC)
- Event streams and change-data-capture pipelines (Kafka/CDC)
- Files and object storage (Amazon S3)
- REST APIs
The goal is to make onboarding new data sources a simple configuration exercise rather than a custom integration project.
Open lakehouse storage
Ingested data is stored in a lakehouse architecture using Apache Iceberg tables on S3. Iceberg provides several capabilities that are particularly useful in enterprise environments:
- Schema evolution as source systems change
- Historical versioning and time-travel queries
- Open storage formats that avoid proprietary dependencies
These capabilities support both analytics workloads and AI retrieval patterns without requiring separate storage systems.
Federated querying
A federated query layer powered by Trino resides on top of the lakehouse. Trino can query data stored in the lakehouse while also reaching directly into connected source systems when live access is required. For structured, high-concurrency workloads, Snowflake is used alongside Trino where appropriate.
Because analytics, workflows, and agents all access data through the same query infrastructure, governance and permissions remain consistent regardless of how information is being consumed. A dashboard query, a workflow action, and an AI-powered request all operate within the same access framework.
2. The model layer
The model layer provides services that support AI-powered experiences throughout PDIQ. Rather than relying on a single AI service, the platform uses a layered architecture that separates user experiences, agent execution, retrieval, and model access.
This application layer is the user-facing entry point. Examples include:
- Embedded assistants
- Workflow interactions
- Natural-language analytics
- Conversational interfaces
Agentic runtime
Agent execution is managed through AGNO, an open agent framework. The runtime supports both focused task-specific agents and coordinated multi-agent scenarios. Depending on the use case, agents can retrieve data, execute workflows, invoke tools, or coordinate with other agents to complete a task.
Tools and platform services
Agents interact with the platform through governed tools and services. Those tools connect to the same data sources, integrations, workflows, and APIs available elsewhere in the platform. This approach keeps AI capabilities aligned with existing operational controls and audit requirements.
Retrieval and grounding
Many AI interactions depend on Retrieval-Augmented Generation (RAG). When additional context is required, agents retrieve relevant information from documents, operational data, and other connected sources before generating a response. Retrieval is supported through embeddings, vector search, and evaluation frameworks that help measure response quality and relevance.
Model access
PDIQ accesses underlying language models through a pluggable adapter layer that allows PDIQ to support multiple model providers while maintaining a consistent platform architecture. As model capabilities evolve, new providers and models can be introduced without requiring changes to workflows, agents, or application experiences.
3. The orchestration layer
The orchestration layer coordinates how platform services interact, primarily covering workflow and agent orchestration, along with governance and deployment.
Workflow orchestration
A workflow can combine traditional automation steps with AI-powered decision points while maintaining a single execution path. Workflow orchestration manages area such as:
- Triggers
- Business logic
- Data movement
- System integrations
- Human approvals
- Agent execution
Agent orchestration
Inside the agent runtime, orchestration focuses on reasoning and task coordination. An agent can determine which tools to call, which data to retrieve, or which additional agents should participate in a task. For more complex scenarios, multiple agents can work together through coordinated execution patterns. Reusable capabilities are packaged as skills and can be shared across different workflows and use cases.
Shared identity and governance
This architecture operates within the same governance framework introduced in the previous post. Every request carries user identity and permission context throughout the platform.
The same controls apply whether a user is:
- Running an analytics query
- Executing a workflow
- Invoking an agent
- Accessing operational data
Authentication, authorization, and auditability remain consistent across all platform capabilities. This allows AI-powered experiences to operate against live operational systems while respecting the same access boundaries already established elsewhere in the organization.
Deployment architecture
PDIQ is deployed on AWS and supports multiregion deployment patterns for resiliency and data residency requirements. Depending on customer requirements, the platform can operate as a multitenant service or within customer-managed environments. The underlying architecture remains consistent across deployment models while providing flexibility for different compliance and operational requirements.
Up next in the PDIQ Insider blog series
The next installment in the PDIQ Insider series will explore a practical architectural challenge many organizations encounter when deploying AI: determining which decisions require real-time processing, which can run on schedules or batches, and how both approaches can operate within the same platform.