Agentic work, with controls
Agents, decisions, human review and approved tools operate through governed platform boundaries, rather than acquiring unrestricted enterprise authority.
by Nu10Book a PIE Demo PIE Enterprise · Provable. Intelligent. Executable.
A customer-hosted target architecture for enterprise AI. Keep the platform and its data services inside your chosen boundary, and control connections to business systems and AI providers.
This reference supports assessment on AWS, Azure or GCP; it does not certify production deployment on any or all of them. Complete customer-local backend provisioning, production hardening and cloud-specific acceptance remain prerequisites for each installation.
Deployment topology
Select a block to explore its purpose and qualifications. Choose a cloud to see illustrative—not certified—service mappings.
Conceptual topology, not an installation specification. Identity/data endpoints, authorised object access and optional callbacks require routing validation. High availability is not certified. A customer-approved identity provider can be a federated shared service outside the account.
Platform operation
The reference brings the web experience, APIs and governed execution together. It does not establish independently scaled web-only and worker-only deployments.
Agents, decisions, human review and approved tools operate through governed platform boundaries, rather than acquiring unrestricted enterprise authority.
Scheduling and resumable work depend on the application and its durable customer data services. Restart, recovery and concurrent execution need validation with your workload.
Compatible identity and authorised data services are required alongside the database. Workspace membership, permissions and publication controls remain part of the installation.
Knowledge and execution records remain in the selected data plane. Binary documents and related artefacts use compatible object storage where enabled.
Kubernetes is recommended, not mandatory. Alternative supported container arrangements require their own qualification. Detailed dependencies and installation specifications are confirmed during technical evaluation.
Data residency
A private network alone does not guarantee residency. The boundary also depends on the endpoints, payloads and access arrangements you select.
Use approved providers, minimum necessary payloads, retention policies and contractual data-processing terms.
Enterprise systems remain their own systems of record. Mapped inputs, outputs, extracted text and agent conversations may still be retained in PIE execution records.
Customer-local inference is a configurable-endpoint option requiring model, embedding and adapter qualification. Complete air-gapped operation is not asserted and remains on the product roadmap.
Trust boundaries
Keep application and data services in restricted zones. Authorised browsers must still reach the identity/data endpoints and object-access routes required by enabled features; those routes need not be publicly exposed.
External handlers must authenticate callers or enforce an approved scoped guest contract. WAF and rate controls complement authorisation. Callbacks need approved ingress or a compatible polling design.
Test real federation, login and token propagation. SSO does not automatically grant workspace access. Automatic user provisioning, attribute-to-role mapping and broader federation modes are not established by this reference.
Require TLS and customer-controlled encryption for databases, objects and backups. Do not assume uniform application-level encryption across every credential store or automatic external-vault lookup. Confirm coverage and integrations for the actual installation.
Enabled APIs and tool surfaces require authenticated, workspace-scoped permissions. Outbound calls send approved data to selected endpoints. External agents do not gain human-only approval or publishing authority merely through tool access.
Agree operator roles, approved support access and emergency procedures. A customer-owned account does not by itself prove vendor-free operation or guaranteed vendor exclusion from customer data.
Infrastructure scope
Requirements depend on enabled features and operating objectives. Size from representative workload measurements—not template defaults.
15 of 15 components
| Component | Purpose | Classification | Location | Qualification | Size from |
|---|---|---|---|---|---|
| Application runtime | Web experience, APIs and governed execution | Required | Private application zone | Supported, version-consistent PIE container distribution | Sessions, requests, workload mix and measured resource use |
| Container orchestration | Placement, scaling and application lifecycle | Recommended; not mandatory | Customer account / private nodes | Compatible container platform; health checks and policies need acceptance | Replicas, failure zones and upgrade windows |
| Identity and authorised data services | Sessions and authorised application data access | Required; complete provisioning needs confirmation | Customer-local application / data plane | The complete compatible backend must be provisioned and validated. A managed database alone is not sufficient. | Authentication traffic, API demand and connection budgets |
| Relational data services | Configuration, execution records, evidence and knowledge | Required | Restricted customer data plane | Database, extension and access-policy compatibility must be validated | Write volume, retention, knowledge volume, I/O and connections |
| Object storage | Binary documents and related artefacts | Workload-dependent | Customer-controlled storage; approved private access | Compatible object interface and authorised browser access must be qualified | Document sizes, retention, requests and recovery volume |
| Ingress, DNS and TLS | Authorised application and API access | Required capability | Private by default; public only where selected | Approved browser/API routes and managed certificates | Connections, request rates, payloads and availability needs |
| Scheduling and background execution | Scheduled work and resumable execution | Required platform capability | Application and customer data plane | Execution, recovery and any external scheduling interface must be validated | Work backlog, waiting work, execution duration and contention |
| Secrets and key delivery | Secure configuration, signing and protected settings | Required capability; vault choice optional | Customer operational boundary | Secure delivery, rotation and recovery are required. Automatic external-vault lookup is not established. | Secret inventory, rotation, recovery and access policy |
| Enterprise identity provider | SSO and customer MFA policy | Required for SSO; may be an existing service | Customer service or approved federated provider | Supported federation and real sign-in must be tested; SSO alone does not grant workspace access | Login demand, user lifecycle and token availability |
| AI inference and embeddings | Agentic reasoning and knowledge AI workloads | Workload-dependent | Approved external or qualified local endpoint | Model, embedding and adapter compatibility require qualification | Token demand, context, latency and quotas; local compute if selected |
| Mail service | Notifications and enabled email flows | Workload-dependent | Customer relay or approved external service | Supported routing, sender and provider configuration | Delivery volume, retries, retention and provider quotas |
| Telemetry and log destination | Operations and optional trace export | Recommended; trace export optional | Customer collector or approved destination | Export compatibility must be tested; infrastructure log collection is separate | Event volume, retention and export-failure policy |
| Backup and availability services | Data protection, recovery and failover | Required for production recovery objectives | Customer account / approved recovery region | Coordinated data, object and key backup with measured restore. High availability is not certified by this reference. | Data change rate, agreed recovery objectives and failover testing |
| Software distribution | Installation and updates | Required operational capability | Customer registry or agreed channel | Versioned distribution, provenance and installation acceptance | Update cadence, transfer volume and delivery constraints |
| Enterprise integrations | Business systems, APIs and approved tools | Workload-dependent | Internal or approved external systems | Adapter, protocol, scopes and reachability must be qualified; not every product has a native connector | Call rates, payloads, endpoint limits and retry behaviour |
Illustrative mappings
These are candidates for compatibility assessment—not a list of certified PIE services. Selecting a cloud highlights its column without removing the qualifications.
| Capability | AWS | Azure | GCP | Qualification |
|---|---|---|---|---|
| Private cloud network | VPC | VNet | VPC | Customer-owned network boundary |
| Managed Kubernetes | EKS | AKS | GKE | Recommended target; cluster and installation acceptance required |
| Managed PostgreSQL | RDS for PostgreSQL | Azure Database for PostgreSQL | Cloud SQL for PostgreSQL | Validate database and backend compatibility. A managed database does not replace required identity and authorised data services. |
| Object storage | S3 | Blob Storage | Cloud Storage | S3-compatible access is the verified interface in the supplied reference. Native Azure/GCP APIs require a qualified adapter or compatible gateway. |
| Secrets and key management | Secrets Manager / KMS | Key Vault | Secret Manager / Cloud KMS | Customer secret delivery and infrastructure encryption. Automatic application-to-vault resolution is not established. |
| Application ingress | Elastic Load Balancing | Application Gateway / Load Balancer | Cloud Load Balancing | Private by default; selected public paths and TLS must be configured |
| Infrastructure observability | CloudWatch | Azure Monitor | Cloud Monitoring / Logging | Customer operations tooling; optional PIE trace export is a separate interface |
| Container registry | ECR | ACR | Artifact Registry | Customer mirror or agreed delivery; distribution qualification required |
Account-scoped object storage may sit outside the private subnet and still use customer-approved connectivity. Managed PostgreSQL does not replace the required identity and authorised data backend.
Operating ownership
A proposed split for agreement—not a managed-service or support commitment. Customer account ownership does not determine who operates each component.
| Area | Proposed responsibility | To agree |
|---|---|---|
| Cloud, network, DNS and TLS | Customer | Topology, access and connectivity |
| Supported PIE distribution | Nu10 | Delivery channel and support scope |
| Installation and upgrades | Shared | Operator, migration window and rollback plan |
| SSO, permissions and key policies | Shared | Customer identity provider and PIE permission mapping |
| Database and object storage | Customer / contracted operator | Failover, retention and recovery ownership |
| Monitoring and backups | Customer / contracted operator | Alert routing and restore cadence |
| Incidents and support access | Shared / contractual | Escalation, approved access and service levels |
Deployment acceptance
This architecture commits no CPU/RAM sizing, concurrency capacity, RPO, RTO or SLA.
Qualify replica coordination and recovery using representative work. There is no universal exactly-once guarantee for external side effects: review connector idempotency and retry handling.
A recommended design uses failure-zone separation, resilient data services and redundant ingress. Scale-out, node loss and database failover must be tested in your environment; high availability is not certified by this reference.
Back up data, objects, configuration and recoverable key material as a coordinated set. Perform an isolated restore and reconcile in-flight external actions.
Validate software and data changes together. Zero-downtime upgrades are not assumed, and rolling back an image alone may not reverse data changes. Agree a recovery procedure before production.
Production approval
Record acceptance results and unresolved constraints before describing an installation as production-ready.
Start with your cloud, identity, data boundary and operating requirements. Confirm what fits, what needs qualification and who owns acceptance.
Discuss your deploymentPublic deployment reference. Detailed engineering specifications are discussed during technical evaluation.