Part of our Blog

Enterprise AI

Domino as an AI Agent Platform

Why Domino’s identity, ACLs, documents, views, agents and offline-first heritage make it a strong governed execution layer for AI Build agent implementations.

Secure Domino-based AI agent workspace with identity, access controls and business workflows

Summary

How AI Build implements HCL Domino as an AI agent layer using Domino IDs, ACL-bound NSF access, mail, calendar, tasks, agents and MCP reach.

Written by Founder & Lead Architect

Reviewed by AI Build GroupEditorial review

Published Last updated

Direct answers

Quick answers

Is this an official HCL product claim?
No. This article describes AI Build’s implementation approach for using Domino in governed AI agent workflows. It is not a claim that HCL has productised this exact platform.
Why is Domino useful for AI agents?
Domino already contains identity, ACLs, documents, views, mail, calendar, tasks and business logic. Those features help AI agents act within existing enterprise controls.
Can an AI agent respect Domino database permissions?
Yes, the intended architecture is permission-aware. Agents should operate through approved identities and respect ACL-bound NSF access instead of using unrestricted data extraction.

A HCL Domino AI agent can be valuable when it respects the way Domino already governs work: user identity, ACL-bound NSF access, mail, calendar, tasks, views, documents and existing agents. AI Build’s implementation uses Domino as a governed enterprise agent layer. It is AI Build’s architecture and delivery approach, not a claim that HCL itself has productised this exact platform.

## In brief Domino is more than a legacy application store. For many enterprises it is still a permissioned operating environment for business processes, correspondence and records. AI Build uses that foundation to give AI agents controlled reach: Domino IDs, ACL-aware data access, existing views and agents, offline tasks, and MCP connectors that extend capability without bypassing governance.

## Why Domino is a strong agent foundation Agentic AI needs a place to act. Domino already has concepts that modern AI programmes often have to recreate: authenticated users, application-level security, database ACLs, document structures, workflow logic and operational history. That makes it a strong candidate for enterprises that want useful agents without replatforming every process first. In a Domino environment, the question is not simply “can an LLM read this?” It is “which identity is acting, which NSF can that identity access, which view or document is appropriate, and what business rule applies?” Those are the questions that make AI safe enough for enterprise work.

## Domino IDs and ACL-bound NSF access Domino IDs and ACLs are central to the implementation. An AI agent should not retrieve every document in a repository just because a user asked a broad question. It should work through an approved identity and respect the same access boundaries that human users and applications respect. That approach supports permission-aware retrieval. If a user can access a sales database but not a HR case file, the agent should follow the same boundary. If an agent service identity is allowed to run a particular task but only on a subset of databases, the platform should enforce that scope. The AI layer becomes a governed participant in Domino rather than an unrestricted back door.

## Mail, calendar and tasks as agent workflows Domino’s mail, calendar and task patterns are also useful agent surfaces. Many business processes start as emails, meetings, follow-ups or recurring tasks. A governed AI agent can help classify messages, draft responses, prepare meeting packs, assemble next actions or track overdue work. The value comes from linking communication with records. For example, an agent can prepare a summary from relevant NSF documents, draft a response in the right tone, and create a task for a human reviewer. The human stays in control, while the agent reduces search, drafting and administrative load.

## Existing views, documents and agents Enterprises have years of Domino investment in views, forms, documents and agents. AI Build’s approach does not assume all of that should be thrown away. Existing views can become curated retrieval surfaces. Existing documents can provide structured evidence. Existing agents can remain part of the process where they are reliable and governed. This is often faster and safer than building an AI layer on top of an unstructured data dump. The Domino application already encodes process knowledge: which fields matter, which status values exist, which users are responsible and which records belong together. An agent can use that structure to reason with context rather than guess from raw text.

## Offline tasks and human approval Not every agent action should be immediate. Some work is best queued as an offline task: prepare a report, check a database, draft a follow-up, compare records or request approval. Offline execution gives the platform time to retrieve evidence, run deterministic checks and route exceptions. Human approval remains essential for sensitive actions. A Domino-based agent can prepare the work, attach evidence and recommend the next step, while approval policies decide what can be sent, changed or published. This is especially important in regulated operations, customer communications and commercial decisions.

## MCP reach beyond Domino MCP extends the agent’s reach beyond Domino without making the model responsible for every integration. A Domino-centred agent can call approved tools for SharePoint, Microsoft 365, web publishing, CRM updates or campaign memory, but each tool call is bounded and auditable. This is where Domino can sit inside the wider AI Build agent platform. Read the broader Enterprise AI Agent Platform overview, the Corporate Memory for AI companion piece and the Enterprise AI Token Economics guide for the retrieval and cost layer.

## What AI Build provides AI Build’s commercial owner for this capability remains HCL Domino Assistant. This support article explains the implementation pattern: Domino as a governed agent foundation, MCP as a controlled tool layer and consulting support where workflows cross systems. If your organisation needs agent design beyond Domino, use AI assistant consulting. If document workflows are the priority, review OfficeMaker. The aim is to deepen the right owner page rather than create duplicate commercial landings.

Questions this briefing answers

Is this an official HCL product claim?
No. This article describes AI Build’s implementation approach for using Domino in governed AI agent workflows. It is not a claim that HCL has productised this exact platform.
Why is Domino useful for AI agents?
Domino already contains identity, ACLs, documents, views, mail, calendar, tasks and business logic. Those features help AI agents act within existing enterprise controls.
Can an AI agent respect Domino database permissions?
Yes, the intended architecture is permission-aware. Agents should operate through approved identities and respect ACL-bound NSF access instead of using unrestricted data extraction.
What does MCP add to a Domino agent?
MCP provides a controlled way for the agent to call approved tools and retrieve context across systems while keeping tool permissions and audit boundaries explicit.
Where should a Domino buyer go next?
Start with AI Build’s HCL Domino Assistant page, then use AI assistant consulting if the use case spans multiple systems or needs broader agent governance.

Next step

Keep the weekly control brief coming.

Subscribe for the next AI Build weekly briefing, or talk to us when you want help turning one of these stories into a governed workflow.