The Agentic Control Plane

Most teams adopting agentic AI bolt a chatbot onto an app and hope it behaves. The hard part isn't the model — it's making an autonomous system safe to hand real work, especially work that changes production data.

GraphControl AI enforces an allow-list registry: every data source and action a page exposes to the assistant is declared up front by a developer, and independently re-validated against that registry at execution time — not just checked once at the prompt layer. The agent proposes a change, shows the before/after, and commits only on explicit human confirmation.

That boundary is enforced, not prompted, and it is built once and reused everywhere: the same safety model underneath every product on the platform, and the same one that ships to third-party apps under the "Powered by GraphControl" mark.

GraphControl AI is the control plane itself — identity, permissions, metered AI billing, and the safety boundary — and it runs underneath a portfolio of products rather than being sold as a single vertical tool: HomeAuto, a multi-vendor home-automation marketplace; Moeletsi, an AI legal advisor that drafts and checks documents against a curated knowledge base; and Softlearn, attendance-based tutoring with sessions, progress, and payments in one place.

A new vertical is mostly domain configuration on top of already-shared infrastructure, not a new company. The same engine is also available as an OEM embed: a third party brings its own domain and customers, and GraphControl brings the assistant, the safety boundary, the agent-generated UI, and usage-based billing.

Every business function on the platform — Finance, Medical, Project Management, Annual Operating Procedures, Mechanical 3D Design, Chemical Engineering, Core Network Design, and dozens more — is modeled as an independent, addable "business unit" rather than a hardcoded module.

New units can be provisioned onto an organization dynamically, with no platform redeploy. ADMIN accounts manage which domains their own organization can reach; SUPER_ADMIN accounts operate platform-wide. Leaving a user's domain access unrestricted keeps it unrestricted by default, so composability doesn't come at the cost of accidental lockouts.

This is what makes the platform genuinely multi-tenant and composable rather than a single fixed vertical SaaS product wearing a configurable skin.

Cross-domain communication runs over a global messaging backbone that enforces CloudEvents 1.0 schema compliance — every event carries a validated id, source, type, and timestamp, with an application/json payload.

Topic contracts can be strict: a transaction-log topic like ACDOCA_RecordCreated requires a numeric valueCents field, for example. Messages that fail validation are buffered rather than silently dropped, and the broker returns a descriptive schema-validation error rather than a generic failure — a deliberate choice, since a fleet of AI agents reasoning over event streams needs to know exactly why a message was rejected, not just that it was.

Storage is composable in the same way domains are: data is placed into Hot, Warm, or Cold tiers based on how it's actually used, not treated as one undifferentiated database.

The Hot tier is an in-memory store using Write-Ahead Logging and MVCC rollback for active transactions — the tier active ledgers and real-time accounting entries live in. The Warm tier is a relational document store that evaluates foreign-key constraints as data lands (policy-to-account mappings, for example). The Cold tier is a columnar, partitioned archival engine that converts incoming JSON streams into compressed Parquet files for long-term, cost-efficient storage.

The effect is that recent, high-throughput data stays fast; structured operational data stays consistent; and historical data stays cheap to retain — without three separate systems to reconcile by hand.

Every request is evaluated by an ABAC middleware layer rather than a flat role check. The evaluation walks a real four-step flow: it reads the subject's attributes — role (USER, ADMIN, or SUPER_ADMIN), organization, and allowed-domains list — classifies the resource being requested, checks transport-level requirements, and then applies organization scoping before the request is allowed through.

ADMIN accounts are scoped to their own organization; SUPER_ADMIN accounts operate platform-wide. Because the check happens per-request against real subject and resource attributes, a multi-tenant deployment can guarantee that one organization's users can never reach another organization's domains or data, regardless of how many business units are active on the platform.

The frontend mirrors the backend's composability. A host shell loads independently deployable domain "remotes" at runtime via Module Federation — a business unit like Finance or Mechanical 3D Design ships and deploys on its own cadence, isolated from the host application's release cycle.

A shared, singleton state bridge carries live data, notifications, and AI-proposed actions across the federation boundary, so a change proposed by an embedded assistant in one domain remote can be reflected consistently across the rest of the shell without a full page reload or a monolithic frontend release.

The platform's technical/industrial domains aren't placeholder screens. Mechanical 3D Design is a coordination layer over the CAD and PLM systems where design already happens — not another CAD tool. Requirements carry units, limits and a verification method, and are traced through the functions and parts that satisfy them to the tests and evidence that prove it. When a new CAD revision is imported, the platform diffs it against the revision the baseline was verified against, works out which requirements and budgets it affects, and proposes it as a branch for a human to review and merge. Geometry is rendered in a deliberately read-only WebGL viewport — click-to-select, explode, shaded/wireframe/x-ray — and is never authored in the platform. Chemical Engineering models real process and formulation records through the same workspace shell. Core Network Design treats topology and infrastructure diagrams as live, structured records rendered by the platform's own diagram engine, not static exported files that go stale the moment they're shared.

Three limits are worth stating plainly, because they bound what the above means. Verification is continuous within an editing session rather than a background service — it recalculates on every revision you accept, not on one a colleague accepts elsewhere. CAD import covers glTF, GLB, OBJ and STL, none of which carry an authoritative mass property, so mass for an imported part is an explicit, opt-in estimate from bounding-box volume and an assumed density; it is labelled wherever it appears, and it can raise a warning on a budget but never, on its own, a failure. And the CAD/PLM vendor connectors (Onshape, Fusion 360, SolidWorks PDM, CATIA) are simulated placeholders with no credentials configured — the working change channel is file import plus an on-demand re-check, and nothing polls.

These are proof points for the same underlying thesis: a composable architecture doesn't have to trade away depth in any single domain to stay general-purpose across all of them.