While it is essential for an AI agentic automation platform to be intelligent and expressive, this is not sufficient for enterprise applications. In addition to the normal IT standards that every enterprise application platform must comply with, there are six specific tenets of an AI agent application platform. They go by the acronym “CHARMS”
The platform must comply with a wide variety of enterprise policies, with special consideration for AI guidelines and security concerns.
Requirements:
A primary compliance concern is to ensure that the underlying LLM does not learn from the data and user interactions of the application.
Since AI applications are data-heavy, compliance with data policies is very important. Many enterprises may impose deployment constraints that require the AI agent platform to deploy and run in a sandboxed fashion in the enterprise environment.
Since AI is making decisions and taking actions that might otherwise have been done by employees, the AI may need to have the same "employee training" with respect to rules and policies. Some of these policies may be explicit and some are implicit (staying polite in customer communication, conformance to legal requirements, etc.).
Access control for AI applications will need to distinguish between application designers, human service agents, and end-users. The programming model will need to clearly define the user identity with which each unit of AI logic runs. For example, if an end-user initiates an application workflow, does it run "as the end user" or "as a human service agent" or "as the application designer" or some other identity?
Finally, every enterprise will expect that the AI agent platform can prove these different forms of compliance in a periodic audit process.
Compliance Features in Thunk.AI:
Your data is not used for LLM Learning
Run entirely on your cloud tenant, if desired
Use policy documents to steer AI agent bevior
Enforce and validate conformance to policies
Discover appropriate policies to use in context
Explicit role-based access controls
Utilize post-facto mechanisms to audit AI agent activity
In an enterprise system, it may be essential for trust, regulatory compliance, or correctness, that certain AI actions and decisions be controlled and influenced by human-in-the-loop engagement.
Requirements:
In some situations, the enterprise may require that a responsible human validate and approve any work done by an AI agent.
Some application work may need a workflow where some tasks are performed by AI agents and some by human agents.
In some situations, it may be the AI agent that is checking and verifying the work of the human service agent.
Across the board, it is necessary for all AI actions and decisions to be explainable and traceable by human service agents or admins after the fact.
The AI agent platform must provide the abstractions and mechanisms to ensure that these different human-and-AI-agent collaboration models can occur.
Human-in-the-loop Controls in Thunk.AI
Some actions can require human agents and others can require AI agents
Work can be assigned to different human agents and AI agents based on dynamic attributes
The application can require some AI agent actions to be validated by human agents and vice-versa
The AI agent can dynamically decide to ask a human agent for help or clarification and vice versa
Planning tasks can require human approval or be fully automated
Workflows can be configured to run entirely automatically or not, as appropriate
A human agent or AI agent can decide to dynamically re-assign its work.
AI agents are valuable, of course, primarily because they can operate without a human user or human service agent driving the work and vetting the work. This has to be integrated with all the enterprise systems of record.
Requirements:
Work is driven not just by end-user inputs but also by change events in the enterprise environment. The platform needs to integrate with other business systems and trigger work when appropriate.
The platform needs a programming model that can register simple logic or complex multi-step workflow logic to run automatically when events occur.
The application platform needs to support fully-automated applications (the AI agent does all the work and only escalates to a human when it requires it) as well partially-automated applications (the AI agent does some of the work and the human completes or approves it).
Automation Controls in Thunk.AI
The design-time AI agent can automatically alter the thunk plan to react to human edits
AI agents can react to incoming email and messages and automatically start work
AI agents can automatically react to incoming email and messages to modify existing tasks
AI agents can react to events in external systems and automatically start work
AI agents can automatically assign work to appropriate human agents and AI agents
AI agents can automatically start or recompute AI work in reaction to data changes by a human or AI agent
AI agents can automatically check and validate data changes made by a human or AI agent
Correct and consistent behavior is essential to establish that the AI application is reliable and can be trusted to run automatically. Further, this reliability should be testable and provable to the application designer.
Requirements:
Generative AI models are probabilistic by design. They respond to inputs with some statistical variance. While this is a desirable feature in creative environments, it is not desirable in enterprise environments. This problem has to be explicitly addressed and compensated for in the design of an AI agent platform. Consistency and reliability are essential requirements.
Does the AI do what it was expected to do? This is the concept of correctness. Some of the correctness expectations are explicit (based on instructions provided) and some are implicit. An AI agent platform must ensure correctness despite variable inputs, partially available context, and partially specified instructions. As a practical matter, correctness required platform mechanisms to check, verify, and course-correct as needed.
Correctness controls are not needed only during execution. They are also needed in a quality-control/testing environment (along with versioning and reliable deployment capabilities) as well as in a post-facto audit environment.
Designers, human agents, and end users need to be able to improve the application correctness via interactively scoring/labeling positive and negative results.
The same inputs should repeatably produce the same results. Minor changes in inputs should not create wild differences in outputs. This is the concept of consistency.
Finally, a business environment may require that certain steps of processing be followed and be shown to have been followed. For example, a credit application may require a credit history check to be performed. It does not only matter if the application was "correctly" approved or rejected. It also matters that the process of checking credit history was followed and was shown to have been followed.
Reliability Controls in Thunk.AI
Work done by AI agents complies with schema constraints on the workflow state.
Work done by AI agents complies with organizational policies.
Work done by AI agents can be explicitly checked for consistency
The thunk designer has granular controls for steering the work of AI agents
The thunk designer can specify tests for AI logic that are automatically executed and checked
AI thunks can be versioned to enable deployment stability despite rapid development
Composition and reuse of customizable logic and content are essential for scalable creation and maintenance of applications.
Requirements:
Complex applications are not monolithic. Multiple people have to work together to implement an application. Applications are built in stages and versions, using some prior capabilities and changing or adding others. A composition or modular programming model is needed. There are different levels at which modularity is required:
The underlying engine of intelligence may be a single multi-modal LLM or a combination of models, general purpose or fine-tuned. In different enterprise environments, there may be requirements to work only with specific approved models.
Integration of existing business applications into a platform is usually a complex (API-based connectors require custom code) and fragile (prone to a number of failure modes) process for legacy application platforms. The AI agent platform needs to make this much easier, handling both the discovery of connection APIs and the data mapping work required when invoking the APIs.
Each AI application cannot be expected to be written entirely from scratch. Yet, the underlying LLMs by themselves does not provide any mechanism to compose modular logic. So this has to be provided by the application platform.
The presence of a modular "programming" model enables the creation of an eco-system of shareable and reusable modules. Just as traditional software programs benefit from an eco-system of code libraries and packages that are widely reused, the same concepts have to be supported for AI "programs" written in natural language.
As modules of AI logic are shared and reused, it is important that the application designer be able to customize and control how modular logic is used by their specific application.
Modular Design Mechanisms in Thunk.AI
Different AI models can be used for different AI tasks
Other enterprise applications can be integrated via API discovery and AI-assisted data integration
AI logic (instructions) can be shared and composed across thunks in a modular fashion
AI-based knowledge/content collections can be shared and composed in a modular fashion
Components and modules can be constrained and specialized when they are imported into a thunk
The thunk designer can leverage an eco-system of modular components and services built by others
Thunk definitions can reside in standard source-control systems
In addition to obvious concerns about exfiltration of enterprise data,, AI Agents are susceptible to a new class of security attacks – in particular, a variety of new injection attacks because the boundaries between data and instruction are not precisely defined.
Requirements:
Enterprise knowhow (AI agentic automation instructions) and data (content used during AI agentic automation) should not be incorporated or “learned” by AI models
Data provided as inputs to the AI automation should not be treated as instructions (as this enables many kinds of injection attacks).
Explicit mechanism to provide automation instructions via SOP (Standad Operating Procedure) documents, distinguished from content documents.
Content provided via tool calls to other business systems of record or external systems (eg: web search results) should not be treated as instructions (as this enables many kinds of injection attacks)
Untrusted internal or external users should not be able to impersonate the identity of other employees via AI agentic logic.
Reliability Controls in Thunk.AI
Conforms to the “model spec” of each LLM model to maximally utilize the native security mechanisms built into the model training
Clear separation of instruction and content in the application model.
Separate security checking for all inputs and all tool outputs.
Use of separate LLM models for agentic execution and security checking
Human confirmation before enabling access to specific AI tools
Persisted AI fingerprints as auditable records of all agentic activity
These "CHARMS" tenets provide an essential framework to evaluate any AI agent application platforms for enterprise adoption.
Read about the capabilities of the Thunk.AI enterprise application platform