Section 7

Query & Agent Architecture

Users interact with the meeting knowledge base through natural language queries and autonomous agents. Queries retrieve semantically relevant context and synthesize answers with citations; agents operate as configurable jobs that run intelligence workflows on a schedule or on demand.

Query Flow

Every query follows the same retrieval-augmented generation (RAG) path. The embedding step uses the same model that was used at ingest time, ensuring vector space consistency between documents and queries.

User Input
Processing Step
Output

Agent Framework

Agents are autonomous or semi-autonomous jobs that operate on the meeting knowledge base. Each agent targets a specific intelligence layer and is triggered by a schedule or event rather than a user query.

Summarizer
L1

Generates post-meeting summaries with action items, decisions, and open questions.

Cross-Reference
L2

Detects topic and entity overlap across streams within configurable time windows.

Trend Detector
L3

Identifies emerging patterns and recurring signals over longer time horizons.

Alert Agent
Cross

Proactively notifies stakeholders when configurable trigger conditions are met.

Report Generator
Cross

Produces periodic briefing documents and executive summaries on demand.

Execution Model

Each agent is a configurable job definition composed of four elements. Definitions are stored in the relational DB and editable through the admin interface. The Job Runner handles all scheduling and execution.

Trigger

Schedule (cron), event (meeting ended), or manual invocation via admin UI.

Scope

Which meeting streams, time windows, and metadata filters the agent operates against.

Prompt Template

The instruction set passed to the reasoning model, parameterized by scope results.

Output Destination

Where results are written — notification channel, report store, or webhook.

Reasoning Model Strategy

The reasoning model is configurable per agent and per query type. This allows cost optimization: simpler L1 summaries can use a faster, cheaper model while complex L3 synthesis and executive reports reserve the highest-capability model. The model selection strategy is a first-class configuration concern, not a hard-coded choice.

ModelStrengthsUse Case
Claude Sonnet 4Strong reasoning, good cost/performance balanceDefault query and agent model
Claude Opus 4Highest reasoning capabilityComplex L3 synthesis, executive reports
GPT-4oStrong general purposeAlternative / fallback
Local models (Llama, Mistral)No API costs, full data privacyFuture option if API cost or data sensitivity becomes a concern