Skip to main content

Site Application AI Capability Architecture

1. Purpose​

This documentation defines how AI and GenAI capabilities are represented, configured, integrated, executed, governed, and exposed inside the Site Application.

It defines a vendor-neutral platform model and uses current official specifications and product documentation for technology-specific terminology.

The architecture treats the following as separate concerns:

  • Capability classification: Assistant, Agent, Automation, Autonomous.
  • Model access: direct provider APIs and client SDKs.
  • Agent runtime: agent SDKs and orchestrators.
  • Knowledge: documents, chunks, embeddings, vector stores, retrieval, and reranking.
  • Memory and state: conversation/session state and execution state.
  • Tools and connectivity: APIs, OpenAPI, MCP, connectors, functions, jobs, and events.
  • Identity: Site identity, SSO, delegated identity, service identity, and permissions.
  • User experience: native Site UI, embedded components, browser/iframe components, and redirects.
  • Registration and configuration: Standard Packages, Data Packages, capability registry, and business-object assignment.

2. Core Architecture Principle​

The Site Platform should not be tied to one AI vendor, one agent framework, or one low-code product.

flowchart TD
    S(["Site Application"]):::actor --> U(["User Experience"]):::actor
    S --> E(["System Events"]):::actor
    U --> R[("AI Capability Registry")]:::store
    E --> R
    R --> A[["Assistant"]]:::model
    R --> G[["Agent"]]:::model
    R --> W[["Automation"]]:::process
    A --> P["Execution Policy"]:::govern
    G --> P
    W --> P
    P --> AU[["Autonomous Mode"]]:::model
    AU --> M["Model Layer<br/>Provider APIs / SDKs"]:::model
    AU --> K["Knowledge Layer<br/>RAG / Memory / Vector"]:::store
    AU --> T["Tool Layer<br/>API / MCP / Jobs"]:::process
    M --> X["Enterprise / Site Systems"]:::external
    K --> X
    T --> X

    classDef actor fill:#DBEAFE,stroke:#1D4ED8,stroke-width:1px,color:#0B1220
    classDef process fill:#EEF2F7,stroke:#475569,stroke-width:1px,color:#0B1220
    classDef model fill:#EDE9FE,stroke:#6D28D9,stroke-width:1px,color:#0B1220
    classDef store fill:#CCFBF1,stroke:#0F766E,stroke-width:1px,color:#0B1220
    classDef govern fill:#FFE4E6,stroke:#BE123C,stroke-width:1px,color:#0B1220
    classDef external fill:#F1F5F9,stroke:#64748B,stroke-width:1px,color:#0B1220,stroke-dasharray:4 3

3. The 4 A's​

CapabilityWorking DefinitionPrimary RoleTypical Human Involvement
AssistantUser-facing AI capability that understands, retrieves, generates, explains, or helps complete a task.User assistanceHigh
AgentGoal-oriented AI runtime that can reason, select tools, execute actions, observe results, and continue across multiple steps.Goal executionMedium
AutomationPredefined process that executes configured steps, rules, workflows, events, or integrations. AI reasoning is optional.Deterministic process executionLow
AutonomousOperating mode in which the system can continue toward an objective, re-plan, decide, and act within defined policy boundaries with limited human intervention.Independent operationVery low / exception-based

The 4 A's are a Site Platform taxonomy, not an external industry standard.

Automation is intentionally orthogonal to the Assistant -> Agent -> Autonomous progression. An agent can invoke automation, and an autonomous capability can coordinate agents and automations.

See 4 A Capability Model.

4. Technology Roles​

Technology TypePlatform RoleExamples
Model / inference providerGenerates or reasons over model inputOpenAI, Gemini, Claude, local model runtimes
Model client SDKLow-level application access to model/provider APIsProvider SDKs, HTTP clients
Agent SDKManages agent loops, tools, state, handoffs, guardrails, tracing, or multichannel behaviorOpenAI Agents SDK, Microsoft 365 Agents SDK
Low-code AI orchestratorVisual construction of assistants, chat flows, agent flows, RAG, and tool orchestrationFlowise
Workflow automation engineDeterministic workflow, trigger, schedule, integration, and business automationn8n
AI interaction UIUser-facing chat/model/knowledge interfaceOpen WebUI
Knowledge/retrieval layerStores and retrieves grounded contextVector databases, document stores, retrieval services
Tool protocolStandardized model-to-tool/context integrationMCP
API descriptionStandard description of HTTP APIsOpenAPI
Identity providerSSO, identity federation, tokens, rolesKeycloak, Microsoft Entra ID

5. Implementation Modes​

The same Site capability may be implemented in multiple ways.

ModeUse WhenSite Representation
Direct APISmall, controlled model call or tool callStandard Package connector
Client SDKApplication needs provider-native SDK featuresComponent / server module
Agent SDKTool loops, sessions, handoffs, guardrails, or multistep reasoning are requiredAgent runtime implementation
Low-code flowVisual flow authoring and fast orchestration are valuableFlow reference in registry
Automation workflowProcess sequence is predefinedAutomation/workflow reference
Embedded applicationExternal application's own UI is required inside Siteiframe/browser component
Redirected web applicationEmbedding is not supported or not appropriateBrowser/URL component

The Site capability definition should remain stable even when its implementation mode changes.

6. Platform Requirements​

The Site AI architecture requires the following capabilities:

  1. Support both direct code/SDK integration and low-code integration.
  2. Separate general model/client SDK access from agent-oriented runtime behavior.
  3. Store reusable configuration through Standard Package settings rather than hard-coding provider credentials.
  4. Allow custom URL/API connectors in addition to built-in connectors.
  5. Maintain knowledge sources from text and uploaded files.
  6. Support document splitting, embeddings, vector storage, similarity retrieval, metadata, and reranking.
  7. Support API connectivity through direct APIs and MCP where appropriate.
  8. Register assistants/agents and associate them with flows, users, business objects, and permissions.
  9. Support SSO and external identity integration for embedded AI applications.
  10. Support Microsoft 365 access through Microsoft Graph where a process needs mail, Teams, files, users, or other Microsoft 365 data.
  11. Support embedded components, connector components, custom URL components, and iframe-based UI integration.
  12. Support prompt templates with variable inputs and task-specific instructions.
  13. Prefer a common capability model where practical instead of unrelated data models for every AI implementation.

7. Canonical Technical Rules​

The following rules are normative for the Site AI architecture:

  • Embeddings are floating-point vectors, not binary 0/1 representations.
  • Chunk sizes are configuration, not fixed at 1000-1500 characters. Token-based and semantic chunking are preferable where supported.
  • Vector stores do not place documents "inside the LLM". They store searchable chunks/embeddings and return relevant context to the model.
  • Session memory is not the same as knowledge storage. Conversation state and persistent knowledge need separate lifecycle and access rules.
  • MCP is a protocol, not simply an API response schema. MCP uses JSON-RPC and exposes primitives such as tools, resources, and prompts.
  • OpenAPI and MCP solve different problems. OpenAPI describes HTTP APIs; MCP standardizes how AI hosts connect to tool/context servers.
  • Sandbox execution is capability-specific, not mandatory for every agent. Use isolation when tools need files, code execution, browser/computer control, or an untrusted workspace.
  • Microsoft Graph SDK, Microsoft 365 Agents SDK, and Microsoft Agent 365 SDK are different products. Graph SDK is for Microsoft Graph API access; Microsoft 365 Agents SDK builds agent applications; Agent 365 SDK adds governed enterprise capabilities to agents built with supported frameworks.

8. Documentation Map​

9. Official References​