Una arquitectura de cuatro capas para un agente de informes ejecutivos en Azure
Cómo un agente de elaboración determinista distribuye el trabajo entre Fabric, procedimientos almacenados en SQL, FastAPI en Azure Functions y Copilot Studio para generar documentos ejecutivos.
Cualquiera que prepare a un ejecutivo para una reunión con clientes sabe cuán dispersa está la información bruta. Los registros del CRM se encuentran en un sistema, las cifras de ingresos en otro, el uso de los productos en un tercero, y la narrativa estratégica debe ser compilada a mano a partir de todos ellos. La función de resumen del “jefe de gabinete” está diseñada precisamente para esa tarea: una persona solicita un resumen en lenguaje sencillo, y la plataforma devuelve un documento listo para ser presentado por el ejecutivo, elaborado a partir de datos operativos, financieros y relacionados con la adopción de inteligencia artificial fragmentados.
Lo que hace que este diseño merezca ser estudiado es lo poco que deja al azar. En lugar de pedirle a un modelo que escriba el resumen a partir de una instrucción, reemplaza la agregación manual por una orquestación regulada por contratos. Los datos se consolidan bajo un marco de gobernanza, se agrupan mediante SQL determinista, se enrutan a través de servicios sin estado y se entregan mediante un flujo conversacional controlado. La arquitectura establece límites estrictos de ejecución en cuatro capas: fundación, datos, servicios y experiencia, de modo que los resultados puedan reproducirse, auditarse y entregarse a la velocidad empresarial dentro de estrictos límites de seguridad.
Diseñado como resultado de un esfuerzo interno de incubación de IA dentro del ecosistema de Microsoft, las afirmaciones sobre rendimiento y resultados que se presentan a continuación provienen directamente de sus creadores y no han sido medidos de forma independiente. Es especialmente útil para arquitectos empresariales, ingenieros de IA y responsables de plataformas que necesitan sistemas de IA deterministas capaces de separar la consolidación de datos, la agregación SQL, la orquestación sin estado y los flujos de trabajo conversacionales.
El diseño de cuatro capas
El agente sigue un modelo de orquestación de cuatro capas, donde cada capa tiene una función específica y abarca varios servicios de Azure así como límites de seguridad:
- Fundamento: un Microsoft Fabric Lakehouse que consolida los datos bajo un marco de gobernanza.
- Datos: Fabric SQL (un almacén de datos o punto de conexión SQL) que contiene procedimientos almacenados para consultas operativas y agregaciones.
Juntos forman un pipeline de inteligencia unidireccional. Los datos se curan y gestionan en la capa base, se agregan de manera determinista en SQL, se procesan mediante lógica de dominio en la capa de servicio y finalmente se presentan a través de interacciones en lenguaje natural. Cada capa mantiene un contrato explícito con sus vecinas, de modo que el elemento de IA contribuye a la toma de decisiones sin complicarla.
Capa fundamental: consolidación gestionada de datos
Microsoft Fabric funciona como la plataforma analítica unificada y como la única fuente de verdad para los detalles de las cuentas, la información financiera, las métricas de uso y las tendencias históricas. La regla fundamental es sencilla: almacenar los datos una vez y reutilizarlos muchas veces, de modo que no haya duplicados entre los sistemas.
Un pipeline se actualiza diariamente, extrayendo y fusionando datos empresariales de Dynamics 365, sistemas financieros y APIs externas. El horario establecido permite ventanas de procesamiento predecibles y asegura que cada sistema fuente haya completado su trabajo diario antes de comenzar la consolidación. El lakehouse mantiene los datos en su formato original, junto con estándares de trazabilidad y gobernanza; posteriormente, los conjuntos de datos refinados pasan a Fabric SQL, la capa de consultas operativas rápida cuyas estructuras están optimizadas para generar informes ejecutivos.
Capa de datos: un motor operativo diseñado para el acceso a APIs
Esta capa convierte los datos básicos seleccionados en contratos de consulta deterministas y de baja latencia para la generación de resúmenes. Establece límites estrictos de agregación y las garantías de rendimiento que los ejecutivos esperan de una herramienta ágil.
Arquitectura. Fabric SQL Warehouse es una interfaz relacional que envuelve todas las operaciones de datos relacionadas con los informes dentro de procedimientos almacenados. La capa de servicio nunca consulta las tablas directamente. Las uniones complejas entre tablas, el significado de cada agregación y la lógica empresarial se ejecutan dentro de la base de datos y no en el código de la aplicación, lo que mantiene los tiempos de respuesta predecibles incluso con grandes volúmenes de datos. El SQL está optimizado para consultas operativas, no para exploraciones analíticas, y su diseño busca uniones deterministas que ofrezcan resultados consistentes, planes de consulta reutilizables para un rendimiento estable, ejecución parametrizada para mayor seguridad y agregaciones encapsuladas que facilitan su mantenimiento.
Filosofía del esquema: consulta primero. El esquema sigue los patrones de consulta y no la normalización típica de los libros de texto. La entidad Account es la estructura principal de agrupamiento, y las tablas auxiliares están organizadas de modo que las uniones se realicen de forma eficiente mediante el identificador comercial, el TPID.
--Accounts Table - Primary Business Entity
CREATE TABLE [aieo].[Accounts] (
[Id] INT IDENTITY(1,1) PRIMARY KEY,
[TPID] BIGINT NOT NULL,
[AccountName] NVARCHAR(255) NOT NULL,
[AccountNumber] NVARCHAR(50),
[SearchTokens] NVARCHAR(500),
[Segment] NVARCHAR(100),
[Industry] NVARCHAR(100),
[ACR_FY25] DECIMAL(15,2),
[RevenueRank] INT,
[CreatedDate] DATETIME2 DEFAULT GETUTCDATE(),
[LastSync] DATETIME2,
[IsActive] BIT DEFAULT 1
);
CREATE CLUSTERED INDEX IX_Accounts_TPID ON [aieo].[Accounts]([TPID]);
CREATE NONCLUSTERED INDEX IX_Accounts_Name ON [aieo].[Accounts](
La tabla Accounts es la entidad central, con TPID como su clave de agrupamiento. Esto permite una recuperación aproximadamente logarítmica para las búsquedas más comunes relacionadas con cuentas, y maneja tanto consultas directas por TPID como búsquedas por nombre.
Tablas auxiliares. Algunas de las tablas auxiliares muestran cómo se gestionan las métricas financieras, los datos de uso de la IA y el enriquecimiento entre sistemas.
-- Revenue Table - Historical and Forecast Data
CREATE TABLE [aieo].[Revenue] (
[TPID] BIGINT,
[FiscalYear] NVARCHAR(10),
[RevenueType] NVARCHAR(20),
[Amount] DECIMAL(15,2),
[LastUpdated] DATETIME2
);
CREATE INDEX IX_Revenue_TPID_FY ON [aieo].[Revenue]([TPID], [FiscalYear]);
La tabla de Ingresos almacena datos financieros de varios años y utiliza índices compuestos adecuados para cálculos de series temporales y tendencias.
-- AI Usage Table - Product Adoption Metrics
CREATE TABLE [aieo].[AIUsage] (
[TPID] BIGINT,
[ProductCategory] NVARCHAR(50),
[UsageLevel] NVARCHAR(20),
[SeatCount] INT,
[AdoptionRate] DECIMAL(5,2),
[LastUpdated] DATETIME2
);
CREATE INDEX IX_AIUsage_TPID_Product ON [aieo].[AIUsage]([TPID], [ProductCategory]);
La tabla de uso de la IA registra la adopción de productos por categoría, lo que permite analizar los patrones de participación y la adopción de tecnologías que son importantes para la planificación de cuentas.
Estrategia de procedimientos almacenados: la lógica empresarial se encuentra en la base de datos. Tres procedimientos principales se encargan de toda la generación de información. SearchAccounts encuentra las cuentas y las clasifica según sus ingresos, GetAccountDetails agrega datos de diversas fuentes para ofrecer un contexto completo a los ejecutivos, y GetBriefingTemplate gestiona la autorización de plantillas según el rol, de modo que solo las personas adecuadas tengan acceso. La capa de servicio llama únicamente a estos procedimientos y no a nada más; no se permite crear SQL dinámico allí.
--Account Search Procedure - Revenue-Prioritized Discovery
CREATE OR ALTER PROCEDURE [aieo].[SearchAccounts]
@searchTerm NVARCHAR(255),
@top INT = 5
AS
BEGIN
SET NOCOUNT ON;
DECLARE @likeTerm NVARCHAR(257) = '%' + REPLACE(REPLACE(@searchTerm, '[', '[[]'), '%', '[%]') + '%'
SELECT TOP (@top)
a.TPID,
a.AccountName,
a.AccountNumber,
ISNULL(acr.ACR_YTD, 0) as ACR_YTD
FROM [aieo].[Accounts] a
LEFT JOIN [aieo].[ACR] acr ON a.TPID = acr.TPID
WHERE
a.AccountName LIKE @likeTerm
OR CAST(a.TPID AS NVARCHAR) = @searchTerm
OR a.AccountNumber LIKE @likeTerm
ORDER BY
ISNULL(acr.ACR_YTD, 0) DESC,
a.AccountName ASC
FOR JSON PATH;
END;
--Account Details Retrieval Procedure - Comprehensive Intelligence Aggregation
CREATE PROCEDURE [aieo].[GetAccountDetails]
(@TPID int)
AS
BEGIN
SET NOCOUNT ON;
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT TOP 1
JSON_QUERY(ap.[AccountProfile]) AS [Account],
JSON_QUERY(ai.[AIUsage]) AS [AI],
JSON_QUERY(acr.[Data]) AS [ACR],
deal.[Deals.AgreementValue],
deal.[Deals.DealType],
deal.[Deals.Term],
deal.[Deals.Remaining],
deal.[Deals.EndDate],
ecif.[ECIF.Committed],
aco.[ACO.IncrementalRevenue],
aco.[ACO.Discount],
aco.[ACO.ACO],
JSON_QUERY(bot.[Data]) AS [BoT],
JSON_QUERY(inv.[Data]) AS [Investments],
JSON_QUERY(rev.[Data]) AS [Revenue]
FROM [dbo].[vw_Customer] P
OUTER APPLY (
SELECT TOP 1
a.[TPID],
a.[CRMAccountName] AS [AccountName],
a.[Segment],
a.[Industry],
a.[EOU],
a.[OU],
LOWER(TRIM(c.[Value])) AS [ATU_Manager.Alias],
aau.[Mail] AS [ATU_Manager.Email],
[dbo].[RemoveJobTitle](aau.[DisplayName]) AS [ATU_Manager.DisplayName],
NULLIF(TRIM(aau.[BusinessPhone]), '') AS [ATU_Manager.PhoneNumber],
JSON_QUERY([am].[Data]) AS [AM],
JSON_QUERY([atum].[Data]) AS [ATUM]
FROM [dbo].[vw_Customer] A
OUTER APPLY STRING_SPLIT(a.[AM], ',', 1) C
LEFT JOIN [cm].[vw_AAD_User] AAU ON LOWER(TRIM(C.[Value])) = LOWER(AAU.[UserPrincipalName])
WHERE A.TPID = P.TPID
) ap
WHERE P.TPID = @TPID;
END;
--Template Management Procedure - Role-Based Access Control
CREATE OR ALTER PROCEDURE [aieo].[GetBriefingTemplate]
(
@UserAlias NVARCHAR(200),
@BriefingType NVARCHAR(200)
)
AS
BEGIN
SET @UserAlias = IIF(CHARINDEX('@', @UserAlias) > 0,
LEFT(@UserAlias, CHARINDEX('@', @UserAlias) - 1),
@UserAlias)
SELECT DISTINCT
[BriefingTemplateId],[TemplateDescription],[BriefingType],
[UserAlias],FullName,[Filename],[FileType],[PreviewFilename]
FROM [hr].[DimPerson] p
INNER JOIN [aieo].[ExecutiveOfficeMember] eom ON eom.[PersonnelNumber] = p.[PersonnelNumber]
INNER JOIN [aieo].[ExecutiveOffice] o ON o.[ExecutiveOfficeId] = eom.[ExecutiveOfficeId]
INNER JOIN [aieo].[BriefingTemplate] bt ON bt.[ExecutiveOfficeId] = o.[ExecutiveOfficeId]
UNION
SELECT DISTINCT
[BriefingTemplateId],[TemplateDescription],[BriefingType],
p.EmailName As UserAlias,p.FullName,[Filename],[FileType],[PreviewFilename]
FROM [aieo].[BriefingTemplate] bt
CROSS JOIN [hr].[DimPerson] p
WHERE bt.[UserAlias] = 'ALL' AND p.EmailName = @UserAlias
AND bt.BriefingType = @BriefingType;
END;
Rendimiento y seguridad. Las transacciones utilizan SET NOCOUNT ON para mejorar la eficiencia, y SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED para las operaciones de lectura a fin de que no generen bloqueos. El manejo de JSON se basa en las funciones nativas de SQL Server, JSON_QUERY y FOR JSON PATH, que permiten procesar los datos de manera eficiente y serializarlos directamente desde la base de datos. Solo se permite la ejecución parametrizada, y la identidad de servicio de la aplicación solo cuenta con permisos de ejecución sobre los procedimientos almacenados, sin acceso directo a las tablas.
GRANT EXECUTE ON SCHEMA::[aieo] TO [service_identity];
- No direct table access permitted
Capa de servicio: orquestación sin estado y límite de ejecución
La capa de servicio se encarga únicamente de la orquestación de datos. Recupera datos, renderiza plantillas y no aplica reglas de negocio propias. Cada servicio tiene una única responsabilidad y está ligeramente acoplado, lo que mantiene separadas de manera clara las capas de datos y de presentación.
Superficie de API y validación. Una aplicación FastAPI expone endpoints REST explícitos con contratos de tipo estricto definidos como modelos Pydantic:
POST /api/briefing/generatees el endpoint principal para generar informes, con validación completa de entradas.GET /api/healthinforma sobre el estado del sistema.GET /api/templatesmuestra las plantillas disponibles para el usuario que realiza la solicitud.
from pydantic import BaseModel
from typing import Optional
class BriefingRequest(BaseModel):
account_name_or_tpid: str
meeting_datetime: Optional[str] = None
meeting_objective: Optional[str] = None
ms_attendees: Optional[str] = None
template_type: Optional[str] = None
El modelo aplica una validación estricta y seguridad de tipos, genera automáticamente documentación OpenAPI y corrige la estructura de cada solicitud. Ninguna entrada no estructurada logra pasar por este control.
Modelo de ejecución. El servicio sigue una secuencia determinista de cinco pasos:
- Validación de la solicitud. Los modelos Pydantic se aseguran de que los tipos y las entradas sean aceptables.
- Resolución de la cuenta. El formato de entrada determina si se busca un TPID directamente o si se llama a
SearchAccountspara realizar una búsqueda por nombre. - Recuperación concurrente.
GetAccountDetailsyGetBriefingTemplatese ejecutan al mismo tiempo medianteasyncio.gather(). - Construcción del contexto. Los resultados de las proceduras se asignan directamente a objetos listos para el template sin ningún procesamiento intermedio.
La ejecución asíncrona y el agrupamiento de conexiones a través de una abstracción DatabaseService garantizan que las mismas entradas produzcan siempre los mismos resultados.
Principios rectores. Cinco reglas rigen la capa de servicio. No contiene lógica empresarial, ya que la inteligencia se genera únicamente dentro de los procedimientos almacenados, lo que permite a la capa de servicio evitar las reglas que complican las pruebas y el mantenimiento. Se encarga exclusivamente de la orquestación de datos, coordinando la recuperación y la presentación sin transformar ni calcular nada. El mapeo de contexto es directo, por lo que los resultados de los procedimientos van a las estructuras de plantillas sin desvíos, reduciendo el riesgo de que el significado varíe entre los datos y la presentación. El procesamiento es determinista, lo que garantiza el mismo resultado para la misma entrada independientemente del momento o del estado de la infraestructura. Además, las responsabilidades permanecen claramente separadas: la lógica de datos está en los procedimientos SQL, la orquestación en los servicios Python FastAPI y la presentación en las plantillas Jinja2.
Capa de experiencia: Copilot Studio como motor de conversación
En la parte superior, el marco AdaptiveDialog de Microsoft Copilot Studio convierte una solicitud en lenguaje natural en un flujo de trabajo determinista. Se encarga de la resolución de cuentas, la autorización de plantillas, la integración de datos externos, la generación de documentos y su entrega a través de varios canales. El flujo se ejecuta secuencialmente, desde la primera solicitud pasando por la resolución de cuentas, la autorización de plantillas, la recopilación de datos externos y su entrega a SharePoint, con puntos de decisión y pasos de validación en cada ruta de conversación.
Diálogo principal. El diálogo recopila automáticamente el identificador de la cuenta, define las frases desencadenantes que inician una sesión informativa y establece el punto de entrada principal de la conversación:
kind: AdaptiveDialog
inputs:
- kind: AutomaticTaskInput
propertyName: Account_Name_or_TPID
name: Account Name or TPID
description: The account/customer TPID (unique identifier) or name
shouldPromptUser: true
modelDescription: Create briefing document to prepare for meeting with customer
beginDialog:
kind: OnRecognizedIntent
intent:
displayName: Topic for creating briefing document to prepare for meeting with customer
triggerQueries:
- Generate a briefing document for account Accenture
- I need a briefing for Amazon
- Create briefing for Apple
- I have a meeting with JPMorgan Chase at 4PM
Resolución de cuentas. Una verificación con IsNumeric() clasifica la entrada como un TPID directo o como un nombre de cuenta que necesita ser buscado. Evitar la búsqueda siempre que sea posible reduce las llamadas a la API y acelera la respuesta:
- kind: SetVariable
id: setVariable_IsNumeric
variable: Topic.IsNumeric
value: =IsNumeric(Topic.UserInput)
- kind: ConditionGroup
id: conditionGroup_InputType
conditions:
- id: condition_IsTPID
condition: =Topic.IsNumeric
actions:
- kind: SetVariable
variable: Topic.Account_TPID
value: =Topic.UserInput
Llamada de búsqueda de cuenta. Para los nombres, el flujo llama al punto de extremo de búsqueda de la capa de servicio a través de REST. Codifica con URL los caracteres especiales, se autentica con una clave de suscripción y declara un esquema de respuesta para que los datos se validen automáticamente:
- kind: HttpRequestAction
id: httpRequest_SearchAccounts
displayName: Search Accounts by Name
url: =Global.ApiBaseUrl & "/api/mssales/search/" & EncodeUrl(Topic.UserInput)
headers:
Ocp-Apim-Subscription-Key: =Global.ApiKey
response: Topic.SearchResults
responseSchema:
kind: Record
properties:
accounts:
type:
kind: Table
properties:
account_name: String
tpid: String
total_count: Number
Tarjeta de desambiguación. Si una búsqueda encuentra varias cuentas, una tarjeta adaptativa muestra un conjunto de opciones dinámicas creado con ForAll() a partir de los resultados, donde cada entrada muestra su TPID. Por lo tanto, una entrada vaga no interrumpe la conversación:
- kind: AdaptiveCardPrompt
id: adaptiveCard_SelectAccount
card: "=Concatenate('{
\"$schema\":\"https://adaptivecards.io/schemas/adaptive-card.json\",
\"type\":\"AdaptiveCard\",\"version\":\"1.5\",
\"body\":[
{\"type\":\"TextBlock\",\"text\":\"Multiple accounts found\",\"weight\":\"Bolder\"},
{\"type\":\"Input.ChoiceSet\",\"id\":\"selectedAccount\",\"isRequired\":true,
\"choices\":',
JSON(ForAll(Topic.SearchResults.accounts,
{title: Concatenate(account_name, \" (TPID: \", tpid, \")\"), value: tpid})),
'}],
\"actions\":[{\"type\":\"Action.Submit\",\"title\":\"Continue\"}]
}')"
Autorización de plantillas. A través de GetBriefingTemplate, el flujo verifica si el usuario puede utilizar plantillas ejecutivas, en función de su rol organizacional y su pertenencia a la oficina ejecutiva. El nombre del principal verifica la identidad, el tipo de informe filtra los resultados, y la gobernanza de las plantillas es segura por defecto:
- kind: HttpRequestAction
id: httpRequest_GetUserTemplates
url: =Global.ApiBaseUrl & "/api/briefings/templates?user_alias=" &
EncodeUrl(System.User.PrincipalName) & "&briefing_type=Customer"
headers:
Ocp-Apim-Subscription-Key: =Global.ApiKey
response: Topic.UserTemplates
Tarjeta de detalles de la reunión. La siguiente tarjeta utiliza una revelación progresiva, mostrando los campos obligatorios al principio y ocultando los opcionales detrás de un botón de activación. La carga cognitiva disminuye mientras se recopila aún el contexto necesario para la reunión informativa:
- kind: AdaptiveCardPrompt
id: adaptiveCard_MeetingDetails
card: "=Concatenate('{
\"$schema\":\"https://adaptivecards.io/schemas/adaptive-card.json\",
\"type\":\"AdaptiveCard\",\"version\":\"1.5\",
\"body\":[
{\"type\":\"TextBlock\",\"text\":\"Create Executive Briefing Document\",
\"weight\":\"Bolder\",\"size\":\"Large\",\"color\":\"Accent\"},
{\"type\":\"Input.Date\",\"id\":\"meetingDate\",\"isRequired\":true,
\"label\":\"Meeting Date\"},
{\"type\":\"Input.Time\",\"id\":\"meetingTime\",\"value\":\"09:00\"},
{\"type\":\"Input.Text\",\"id\":\"msAttendees\",\"isVisible\":false,
\"label\":\"Microsoft Attendees\"}
],
\"actions\":[
{\"type\":\"Action.ToggleVisibility\",\"title\":\"Additional Options ▼\",
\"targetElements\":[\"msAttendees\"]},
{\"type\":\"Action.Submit\",\"title\":\"Generate Briefing\"}
]
}')"
Recolección de datos en paralelo y generación de documentos. La capa de experiencia llama simultáneamente a la API Account Details y a Azure AI Foundry, cada una con un tiempo de espera de 60 segundos. Una vez que ambas responden, se crea un payload JSON estructurado a partir de todas las fuentes y se pasa al API de generación de documentos, manteniendo la validación y el ensamblaje de forma autónoma para que la información generada sea determinista.
Azure AI Foundry: inteligencia organizacional
La integración con Foundry amplía el alcance del agente más allá de los datos de mercado externos para incluir contexto proveniente de la organización, utilizando un componente “M365 Researcher”. Utiliza acceso delegado a Microsoft Graph para buscar correos de Outlook y conversaciones en Teams, permaneciendo dentro de los límites de seguridad empresarial y los principios de confianza cero.
Acceso delegado a Microsoft Graph sin secretos almacenados. El investigador cuenta con autenticación delegada que elimina por completo los secretos del cliente almacenados. Utiliza conectores gestionados por Azure Logic Apps, que son aplicaciones de Microsoft de primera parte con alcances delegados previamente acordados. Esto evita la carga de gestionar registros de aplicaciones, ya que Azure se encarga del ciclo de vida de los tokens y de su actualización automática.
Además, las instancias temporales de Logic Apps protegen el acceso a los datos de un usuario mediante desencadenadores HTTP seguros con SAS. Cada búsqueda crea una instancia nueva de Logic App, obtiene datos de Microsoft Graph de forma simultánea y la elimina inmediatamente después, de modo que una URL SAS no pueda ser reutilizada y ningún token persistente quede expuesto.
// Ephemeral Logic App Security Pattern
const createSearchLogicApp = async (userAlias, searchQuery) => {
const logicAppName = `Researcher-${userAlias}`;
// Create Logic App with SAS trigger
const logicApp = await armClient.logicApps.createOrUpdate({
resourceGroupName: 'Azure_OpenAI',
workflowName: logicAppName,
definition: buildResearchWorkflow(userAlias)
});
// Execute search via SAS URL
const searchResults = await triggerLogicApp(logicApp.triggerUrl, searchQuery);
// Immediate cleanup for security
await armClient.logicApps.delete(logicAppName);
return searchResults;
};
Recuperación paralela y ajuste de Graph. Los datos de correo electrónico y de Teams se recopilan al mismo tiempo, con límites de concurrencia para que las sesiones de muchos usuarios no provoquen limitaciones en el rendimiento. En el caso del correo, el conector de Office 365 realiza una recuperación masiva de los 250 mensajes más recientes por usuario, y el filtrado se realiza en el cliente para sortear los límites de Graph en la búsqueda de los cuerpos de los mensajes. En el caso de Teams, se emplea un enfoque en dos fases: primero se identifican las conversaciones mediante llamadas paginadas y luego se recuperan los mensajes de cada hilo de conversación, con un límite de concurrencia configurable.
# Logic App Parallel Execute Pattern
HTTP_Trigger_SAS_Secured:
Email_Branch:
- Get_Emails: Office365_Connector.Mail (top=250)
Teams_Branch_Parallel:
- Get_Teams_Chats_Page1: Teams_Connector.Chats (top=50)
- Get_Teams_Chats_Page2: Teams_Connector.Chats (skip=50, top=50)
- For_Each_Chat:
concurrency: 10
actions:
- Get_Chat_Messages: Teams_Connector.Messages (top=50)
- Append_Chat_Data: Variable_Accumulation
Response_Assembly:
- Combine: Email_Results + Teams_Results + Metadata
- Return: JSON_Structured_Response
Una búsqueda típica realiza unas 101 llamadas a la Graph API: una para el correo, dos para enumerar las conversaciones de Teams y un promedio de 98 para obtener los mensajes de chat. Esto permite procesar una gran cantidad de datos manteniéndose dentro de los límites de concurrencia de Graph y, según el diseño, asegurando que los tiempos de respuesta sean inferiores a 60 segundos.
Conexiones y tokens por usuario. Cada usuario necesita dos conexiones gestionadas que mantengan los tokens OAuth delegados a lo largo de las sesiones de búsqueda: office365-{alias} para el correo con el ámbito Mail.ReadWrite y teams-{alias} para el chat con Chat.Read. La infraestructura de conectores gestionados de Azure actualiza los tokens automáticamente y respalda el cumplimiento normativo. La provisión sigue un flujo basado en el consentimiento, en el cual el usuario inicia sesión una sola vez a través de la experiencia OAuth propia de Microsoft, y los permisos delegados permanecen vigentes hasta que se revocan. La Function App gestiona el ciclo de vida de las conexiones a través de las API de Azure Resource Manager bajo una identidad gestionada, por lo que no se almacenan credenciales de cliente en la capa de la aplicación.
// Per-User Connection Provisioning
const provisionUserConnections = async (userAlias) => {
const connections = [
{
name: `office365-${userAlias}`,
api: '/providers/Microsoft.PowerApps/apis/shared_office365',
scopes: ['Mail.ReadWrite']
},
{
name: `teams-${userAlias}`,
api: '/providers/Microsoft.PowerApps/apis/shared_teams',
scopes: ['Chat.Read']
}
];
for (const conn of connections) {
await armClient.connections.createOrUpdate({
resourceGroupName: 'Azure_OpenAI',
connectionName: conn.name,
properties: {
displayName: conn.name,
api: { id: conn.api },
parameterValues: {}
}
});
}
return generateConsentUrls(connections);
};
Síntesis con un modelo GPT. Las comunicaciones en bruto se convierten en inteligencia organizacional lista para su uso mediante un modelo del Servicio Azure OpenAI (descrito como GPT-4.1, aunque el código de ejemplo menciona una versión de prueba de GPT-4). El proceso transforma el correo filtrado y el contenido de Teams en información estructurada que abarca el análisis de las partes interesadas, los patrones de comunicación y las acciones relevantes para la reunión. Las instrucciones dadas al modelo están orientadas a las necesidades de los ejecutivos, como el mapeo de relaciones, el estado del proyecto y los temas estratégicos, y el modelo devuelve un JSON estructurado que se integra en las plantillas Jinja2 existentes, manteniendo un formato consistente en todos los documentos.
# Organizational Intelligence Synthesis
async def synthesize_organizational_context(filtered_data, account_context):
synthesis_prompt = """
Analyze the following organizational communications for executive briefing preparation:
Account Context: {account_name}
Email Communications: {email_count} relevant messages
Teams Discussions: {chat_count} relevant conversations
Generate executive intelligence focusing on:
Financial performance, earnings trends, and capital allocation signals.
Corporate strategy, market positioning, and competitive landscape.
AI strategy, digital transformation initiatives, and cloud ecosystem alignment.
Recent material developments (≤ 90 days) with actionable insights for executive engagement.
Format as structured JSON with executive_summary, stakeholder_analysis, recent_activities, and recommended_actions.
"""
response = await azure_openai_client.chat.completions.create(
model="gpt-4-1106-preview",
messages=[{
"role": "system",
"content": "You are an executive intelligence analyst."
}, {
"role": "user",
"content": synthesis_prompt.format(**filtered_data, **account_context)
}],
temperature=0.1,
max_tokens=2000
)
return parse_structured_intelligence(response.choices[0].message.content)
Integración en el diálogo. El investigador se une al flujo de trabajo de Copilot Studio en paralelo con la extracción de datos de la cuenta estándar y la inteligencia de mercado externa, por lo que no se espera que el contexto organizacional adicional ralente la generación general de informes.
# Enhanced Copilot Studio Parallel Execution
- kind: ParallelExecution
id: parallelExecution_ComprehensiveIntelligence
branches:
- account_data:
kind: HttpRequestAction
url: =Global.ApiBaseUrl & "/api/accounts/" & Topic.Account_TPID
- organizational_intelligence:
kind: HttpRequestAction
url: =Global.ApiBaseUrl & "/api/search?q=" & EncodeUrl(Topic.Account_Name) & "&alias=" & System.User.PrincipalName
requestTimeoutInMilliseconds: 60000
continueOnError: true
- market_intelligence:
kind: HttpRequestAction
url: =Global.FoundryBaseUrl & "/bingnews/api/AgentFunction"
- kind: SetVariable
id: setVariable_CombinedIntelligence
variable: Topic.BriefingContext
value: ={
account_details: Topic.AccountData,
organizational_context: Topic.OrganizationalIntelligence,
market_insights: Topic.MarketIntelligence
}
Gobernanza y cumplimiento. Los usuarios solo pueden buscar su propio correo y mensajes de Teams a través de permisos delegados, lo que evita el acceso entre usuarios y mantiene estrictas las fronteras de los datos. Cada llamada a la Graph API se registra con el contexto del usuario, los parámetros de búsqueda y los metadatos de los resultados. La retención es configurable, y las conexiones que no se utilizan durante un período definido, generalmente 80 días, se eliminan automáticamente. El procesamiento se realiza dentro del tenant de Azure, y los controles de residencia de datos respaldan las políticas de gobernanza de la organización.
// Enterprise Governance and Cleanup
const implementGovernanceControls = async () => {
// Automated stale connection cleanup
const staleThreshold = 80; // days
const allConnections = await listManagedConnections();
const staleConnections = allConnections.filter(connection => {
const lastUsed = parseISO(connection.properties.lastConnection);
const daysSinceUse = differenceInDays(new Date(), lastUsed);
return daysSinceUse > staleThreshold;
});
// Compliance audit logging
for (const connection of staleConnections) {
await auditLogger.log({
action: 'CONNECTION_CLEANUP',
userAlias: connection.userAlias,
reason: 'AUTOMATED_GOVERNANCE',
retentionPolicy: `${staleThreshold}_DAYS_INACTIVE`,
timestamp: new Date().toISOString()
});
await deleteUserResources(connection.userAlias);
}
};
Rendimiento y tolerancia a fallos. El sistema almacena en caché el estado de conexión del usuario y verifica su estado antes de ejecutar operaciones costosas en Graph. Si Graph está limitado o temporalmente fuera de servicio, el sistema funciona de manera gradual, utilizando un retroceso exponencial para los fallos transitorios y límites estrictos de tiempo de espera para que la generación de informes no se vea afectada. Cuando la búsqueda organizativa falla o se agota el tiempo de espera, el informe sigue enviándose con los datos de la cuenta e información de inteligencia de mercado externa, de modo que los ejecutivos cuenten con una experiencia consistente independientemente de si Microsoft 365 está disponible o no.
// Fault-Tolerant Execution Pattern
const executeOrganizationalIntelligence = async (searchQuery, userAlias) => {
const executionTimeout = 60000; // 60 second maximum
const fallbackResponse = { summary: "Organizational context unavailable", status: "fallback" };
try {
// Health check before expensive operations
const connectionsHealthy = await verifyConnectionHealth(userAlias);
if (!connectionsHealthy) {
return fallbackResponse;
}
// Execute with timeout boundary
const intelligencePromise = gatherOrganizationalIntelligence(searchQuery, userAlias);
const timeoutPromise = new Promise((_, reject) =>
setTimeout(() => reject(new Error('TIMEOUT')), executionTimeout)
);
return await Promise.race([intelligencePromise, timeoutPromise]);
} catch (error) {
// Graceful degradation logging
await logger.warn(`M365 Researcher fallback: ${error.message}`, {
userAlias,
searchQuery,
fallbackMode: true
});
return fallbackResponse;
}
};
Una vez que se cuenta con el investigador, el agente pasa de la inteligencia de mercado externa a una visión integral que incluye información de los interesados internos, con el objetivo de apoyar decisiones estratégicas más acertadas sin comprometer los estándares de seguridad, gobernanza ni rendimiento.
Llamada para generación de documentos. En esta etapa se crea el informe final al combinar todo lo recopilado durante la conversación en un único paquete para la capa de servicio. Este contiene el contexto del usuario, los detalles de la reunión e información adicional opcional proveniente de inteligencia artificial; el proceso completo del documento tiene un tiempo límite de 60 segundos:
- kind: HttpRequestAction
id: p4tceX
method: Post
url: =Global.ApiBaseUrl & "/api/briefings/" & Topic.templateId & "/accounts/" & Topic.Account_TPID
body:
kind: JsonRequestContent
content: "={
user_alias: Topic.SenderEmail,
MeetingDateTime: Topic.MeetingDateTime,
msAttendees: Topic.msAttendees,
FoundryResponse: Topic.FoundryResponse
}"
requestTimeoutInMilliseconds: 60000
response: Topic.BriefingDocument
Entrega a SharePoint. Todos los documentos generados se envían a un repositorio central a través del conector de SharePoint de Power Platform con autenticación gestionada, de modo que cada documento se conserva y queda accesible independientemente del método secundario de entrega, lo cual cumple con las expectativas de gobernanza. El sitio y la carpeta de destino en el ejemplo a continuación son marcadores de posición.
- kind: InvokeConnectorAction
id: invokeConnectorAction_YKkMK4
input:
binding:
dataset: https://microsoft.sharepoint.com/teams/MCAPSAIIncubationHub
folderPath: /Shared Documents/General/AI Prototypes & Solutions/AI Executive Office Use Cases/Published Cust Template/
name: =Topic.CustomFilename
file: =Global.File
Los nombres de los archivos se generan para que sean legibles, combinando el nombre de la cuenta, el identificador del ejecutivo y la fecha de la reunión. Substitute() los hace seguros para el sistema de archivos y mantiene la consistencia en la nomenclatura a lo largo de los flujos de trabajo de los ejecutivos:
- kind: SetVariable
id: setVariable_CustomFilename
variable: Topic.CustomFilename
value: =Concatenate(
Substitute(Topic.Account_Name, " ", "_"), "_",
Topic.ExecutiveName, "_Brief_",
Text(Topic.meetingDate, "yyyy-MM-dd"), ".docx"
)
Manejo de errores y estado. Las fallas al acceder a una plantilla generan indicaciones contextuales en una tarjeta adaptativa de tipo advertencia, en lugar de un error genérico. El flujo examina códigos de error específicos de la API del servicio, informa al usuario qué autorización falta y evita que se muestren detalles sensibles del sistema:
- kind: ConditionGroup
id: conditionGroup_CheckBriefingError
conditions:
- condition: =!IsBlank(Topic.BriefingDocument.error) && Topic.BriefingDocument.error.error_code = "TEMPLATE_ACCESS_DENIED"
actions:
- kind: AdaptiveCardPrompt
card: ={
"$schema":"https://adaptivecards.io/schemas/adaptive-card.json",
"type":"AdaptiveCard","version":"1.5",
"body":[{
"type":"Container","style":"warning",
"items":[{
"type":"TextBlock","text":"Template Access Required",
"weight":"Bolder","color":"Attention"
},{
"type":"TextBlock","wrap":true,
"text": Topic.BriefingDocument.error.user_message
}]
}]
}
La validación empresarial se ejecuta en el cliente, por lo que los datos inválidos nunca llegan a los servicios backend, lo cual mejora la experiencia del usuario y evita llamadas API innecesarias. Por ejemplo, una fecha de reunión en el pasado es rechazada de inmediato junto con indicaciones sobre qué hacer:
- kind: ConditionGroup
id: conditionGroup_ValidateInputs
conditions:
- condition: =Topic.meetingDate < Today()
actions:
- kind: SendActivity
activity: The meeting date cannot be in the past. Please start over and enter a future date.
- kind: EndConversation
Un paso de limpieza sensible desde el punto de vista de la seguridad elimina todas las variables que almacenan datos de cuentas, respuestas de API e ingresos de usuarios cuando finaliza la conversación. Esto satisface las necesidades de privacidad y evita la acumulación de memoria en servicios de conversación de larga duración que manejan información comercial confidencial:
- kind: SetVariable
id: setVariable_ClearUserInput
variable: Topic.UserInput
value: =Blank()
- kind: SetVariable
id: setVariable_ClearAccountDetails
variable: Topic.AccountDetails
value: =Blank()
- kind: SetVariable
id: setVariable_ClearFoundryResponse
variable: Topic.FoundryResponse
value: =Blank()
- kind: SetVariable
id: setVariable_ClearBriefingDocument
variable: Topic.BriefingDocument
value: =Blank()
En conjunto, la capa de experiencia ofrece orquestación conversacional con flujos de trabajo deterministas, manejo exhaustivo de errores, llamadas tolerantes a fallos hacia servicios externos, autorización basada en roles y entrega multicanal a través del framework AdaptiveDialog.
Detalles de seguridad e implementación
Identidad y autenticación federadas
El sistema utiliza credenciales de identidad federada de Azure para que no se almacenen secretos, permitiendo un inicio de sesión consistente en todos los entornos. Un selector de credenciales detecta dónde se ejecuta el código y elige el mecanismo correspondiente:
# Environment-aware authentication pattern
def get_credential():
if is_azure_environment():
return ManagedIdentityCredential(client_id=os.getenv('AZURE_CLIENT_ID'))
else:
return AzureCliCredential()
En Azure se utiliza una identidad gestionada, con credenciales que se proporcionan y rotan automáticamente, mientras que el desarrollo local recurre a las credenciales de Azure CLI. Los tokens se almacenan en caché de manera segura para hilos, y su vencimiento se gestiona automáticamente.
Estructura del servicio y gestión de dependencias
La capa de servicio se basa en la inyección de dependencias, lo que permite que el mismo código funcione con simulaciones en pruebas e instancias completamente configuradas en producción. Las cuestiones transversales como el manejo de errores y la gestión de configuraciones son compartidas por todos los componentes del servicio, y cada uno de ellos (SharePoint, base de datos, Power BI) acepta dependencias opcionales a través de su constructor, manteniéndose así ligeramente acoplado a APIs externas y recursos de Azure. Esto permite realizar pruebas exhaustivas con implementaciones simuladas, así como un comportamiento fiable en producción gracias a una adecuada abstracción.
La orquestación es asíncrona para aprovechar al máximo la recopilación paralela de datos. Cuando se genera un informe, se consultan varias fuentes mediante async/await y un manejo cuidadoso de errores, de modo que el sistema funcione de manera adecuada incluso cuando alguna falla.
Conexiones a la base de datos y rendimiento
La capa de la base de datos utiliza pooling de conexiones a través de la gestión del motor de SQLAlchemy, con un patrón singleton para un uso eficiente de los recursos. Las consultas se concentran en procedimientos almacenados que albergan la lógica de negocio dentro de la base de datos, lo cual reduce el tráfico de red y simplifica el código de la aplicación. Los grandes conjuntos de resultados se manejan reconstruyendo inteligentemente el JSON, superando las limitaciones de pyodbc con respuestas extensas, de modo que el procesamiento siga siendo fiable independientemente del tamaño del resultado y el uso de memoria se mantenga razonable.
Integración de servicios externos
La integración con SharePoint y Microsoft Graph almacena en caché las propiedades de forma perezosa para reducir las llamadas a la API y, al mismo tiempo, mantener los datos actualizados. Los IDs de sitios y unidades de almacenamiento se guardan en caché con una invalidación adecuada y una selección dinámica de bibliotecas, lo que garantiza la fiabilidad de las subidas. La integración con Dynamics 365 analiza las respuestas de Search v2.0 y convierte los resultados brutos en estructuras con significado empresarial, incorporando lógica de intentos repetidos para hacer frente a las limitaciones de velocidad y un manejo cuidadoso de los errores.
Generación de documentos
El pipeline de generación combina el procesamiento de plantillas Jinja2 con la creación de contexto, lo que convierte los datos brutos en información útil lista para su uso por parte de la dirección ejecutiva. El contexto de la plantilla incluye datos brutos, métricas calculadas, herramientas de formato e información obtenida a partir del análisis entre sistemas. La gestión de plantillas valida la sintaxis y maneja errores, lo que garantiza que la generación sea fiable incluso cuando se editan las plantillas. Además, se admiten varios formatos de salida a través de la configuración de tipos MIME para una entrega flexible.
Errores y excepciones
La aplicación cuenta con una jerarquía estructurada de excepciones que proporciona información detallada sobre los errores respetando al mismo tiempo las restricciones de seguridad. Las clases de excepción personalizadas incluyen contexto que facilita la depuración sin revelar los detalles internos del sistema:
Structured exception hierarchy
class AIExecutiveOfficeError(Exception):
def __init__(self, message: str, error_code: str = None, details: dict = None):
self.message = message
self.error_code = error_code or self.__class__.__name__
self.details = details or {}
self.timestamp = datetime.utcnow()
Un manejador de excepciones global convierte los errores técnicos en respuestas API estructuradas que ayudan al llamante sin revelar demasiados detalles.
Evaluación y validación de calidad
El sistema se evalúa mediante un marco de pruebas estructurado que verifica el rendimiento técnico y la calidad de las informaciones en múltiples cuentas empresariales. Se combinan métodos cuantitativos y cualitativos en un proceso de evaluación que prueba cada componente arquitectónico por lotes.
En el aspecto cuantitativo, el enfoque está en la precisión de los datos. Las métricas de las plantillas de informe finalizadas y completas se comparan con los datos originales del nivel base, y el proceso calcula las puntuaciones de precisión y el error porcentual absoluto promedio (MAPE). Estos indicadores muestran hasta qué punto la capa de servicio transmite los datos con fidelidad a lo largo de todo el proceso, desde los resultados de las proceduras almacenadas hasta el documento final. Las ejecuciones por lotes abarcan muchas cuentas y generan un cuaderno de rendimiento consolidado, que proporciona evidencia estadística de que un diseño basado únicamente en orquestación mantiene la fidelidad de los datos sin introducir errores de cálculo ni desviaciones semánticas entre la capa base y la capa de experiencia.
El aspecto cualitativo mide un único atributo: la fluidez en el trato con la empresa, es decir, hasta qué punto un informe demuestra una comprensión real de la organización objetivo y habla de ella de manera adecuada. Un evaluador basado en LLM califica cada informe según cinco criterios estándar: relevancia (¿el contenido es adecuado para decisiones ejecutivas?), coherencia (flujo y estructura lógicos), precisión (exactitud factual y alineación con los datos de origen), claridad (lenguaje y presentación adecuados para ejecutivos) e integralidad (cobertura de las áreas estratégicas). Este enfoque permite una evaluación consistente y escalable con puntuaciones objetivas en diferentes tipos de cuentas e industrias, aunque, al igual que cualquier sistema de calificación basado en LLM, hereda los sesgos propios del modelo del evaluador.
Siguientes pasos: paso al Microsoft Agent Framework
El equipo considera que la arquitectura de cuatro capas constituye una buena base para migrar al Microsoft Agent Framework (MAF), lo cual fortalecería la orquestación de IA manteniendo al mismo tiempo los principios deterministas. MAF se integraría principalmente en la capa de servicios, reemplazando la lógica de orquestación de FastAPI por agentes MAF que siguen los mismos patrones de orquestación de datos puros. La capa de experiencia cambiaría por completo: Copilot Studio daría paso a una integración nativa con Microsoft 365 que colocaría los flujos de trabajo ejecutivos dentro de Outlook, Teams y SharePoint, utilizando la comprensión del lenguaje de MAF para un reconocimiento más preciso de las intenciones y conversaciones multietapa, mientras sigue utilizando los mismos procedimientos almacenados para la inteligencia empresarial.
La capacidad de observabilidad integrada, la gestión ágil y las herramientas para el ciclo de vida de los agentes de MAF eliminarían la necesidad de infraestructura personalizada y añadirían monitoreo y despliegue a nivel empresarial. La ruta de migración mantiene las inversiones existentes en procedimientos almacenados, plantillas Jinja2 e integración con SharePoint, al tiempo que agrega funcionalidades para escenarios más complejos, como reuniones que abarcan varias cuentas, síntesis de análisis competitivo y plantillas generadas dinámicamente a partir del contexto de la reunión y los participantes. Con la integración en Microsoft 365, la generación de informes se convertiría en una funcionalidad integrada en los flujos de trabajo de productividad existentes y no en una interfaz de chat separada, manteniendo los niveles de datos y servicios deterministas.
Lo que muestra el diseño
El agente convierte la preparación de informes de una coordinación manual en una generación automática de inteligencia a través de cuatro capas que separan la consolidación de datos, la agregación operativa, la orquestación empresarial e la interacción en lenguaje natural. Se dice que el enfoque determinista, dentro del ecosistema integrado de Microsoft, permite una generación rápida de informes (la afirmación es de “subsegundos”, aunque los tiempos límite del propio proceso alcanzan los 60 segundos, por lo que lo más probable es que se refiera a las etapas de la base de datos y los servicios), además de ofrecer las características de seguridad, gobernanza y auditoría que los sistemas basados únicamente en comandos tienen dificultades para garantizar.
La lección más importante es que las aplicaciones empresariales exitosas de IA priorizan la resolución del problema comercial sobre la sofisticación técnica, y generan valor a través de una integración sólida de datos y automatización de procesos, más que mediante el aprendizaje automático avanzado. La separación por capas de las responsabilidades, la inyección de dependencias y los límites de ejecución deterministas convierten este diseño en un patrón reutilizable para la automatización del servicio al cliente, los flujos de trabajo de análisis financiero e inteligencia operativa en otras organizaciones.
Leer más
- Formación de agentes de IA empresarial: elegir entre SFT, DPO, GRPO y RAG — Cómo seleccionar el ajuste fino, el ajuste por preferencias, el aprendizaje por refuerzo o la recuperación de información para un agente empresarial, y lanzar el resultado como una versión fija, evaluada y reversible.