AI Agents - Architecture & Data Handling
Monte Carlo takes a feature-by-feature approach to AI and data handling. Each AI Agent is designed with intentional data handling based on what it needs to deliver value while protecting customer data. We don't apply a one-size-fits-all model—instead, we design each feature around the minimum data required for it to be useful.
AI Agents work on top of the data Monte Carlo already collects for core observability—metadata, query logs, lineage, and optionally, data samples. When you trigger an Observability Agent, Monte Carlo determines what information that specific feature needs:
- Metadata only: Some AI Agents only need schema, table names, query patterns, and lineage. No data values required.
- Aggregated information: Some AI Agents work with statistics (row counts, null percentages, distributions) rather than individual records.
- Sample data: Some AI Agents require seeing actual data values to detect patterns, understand formats, or identify quality issues.
Key principle: Each feature uses the minimum data types necessary.
How Data Flows Through AI Agents
sequenceDiagram
autonumber
participant Platform as Core MC Platform/UI
participant Storage as Object storage
participant Job as MC Internal Job(s)
participant Prompt as Prompt
participant Memory as Agent memory
participant Bedrock as AWS Bedrock (LLM)
participant Observability Tooling as Observability Tooling
Platform-->>Job: User triggers LLM feature
Job-->>Platform: Check for relevant data
Storage-->>Job: Read & Retrieve <br/>customer data <br/>(where & how applicable)
Job-->>Prompt: Add relevant <br/>customer data to prompt <br/>(where & how applicable)
Prompt->>Memory: Prompt sent to agent
Prompt->>Observability Tooling: Prompt trace <br/>(redacted when needed)
Memory-->>Bedrock: Agent prompts LLM
Bedrock->>Memory: LLM output sent <br/>back to agent
Memory->>Observability Tooling: Output trace <br/>(redacted when needed)
Memory-->>Platform: Results rendered to UI
When you trigger an AI Agent:
-
Monte Carlo prepares context - Gathers the specific data needed (metadata, aggregated statistics, or samples) from internal systems and object storage
-
Prompt construction - Builds a prompt with feature-specific instructions, the prepared data, and conversation history if applicable
-
LLM processes request - Sent to AWS Bedrock (Anthropic Claude models) for analysis and recommendations
-
Data handling safeguards:
- Samples sent to LLM are immediately discarded after processing and excluded from traces
- Only aggregates or metadata in prompts get full trace logging
- No persistent storage in AWS Bedrock
- User-uploaded files are stored in Monte Carlo's AWS environment for up to 7 days
-
Response delivered - AI-generated insights returned to you in the Monte Carlo UI
-
Conversation memory (for conversational features) - Context maintained up to 30 days in Monte Carlo's AWS environment for follow-up questions
Data Storage & Handling
| Data Type | Where It Lives | Duration | Used For |
|---|---|---|---|
| Metadata (schemas, table names) | Monte Carlo platform | Persistent | Core observability, AI analysis |
| Query logs | Monte Carlo platform | Persistent | Lineage, usage analytics, AI context |
| Data samples | Object storage | Configurable | Data quality monitoring, AI features |
| AI conversation history | Monte Carlo AWS environment | Up to 30 days | Conversational features |
| User-uploaded files | Monte Carlo AWS environment | Up to 7 days | Operations Agent, Support Agent |
| LLM processing | AWS Bedrock | Transient only | Real-time AI inference |
Important:
- AI Agents don't collect new data—they use what's already gathered for core observability
- Data samples only collected when data sampling is enabled
- Warehouse credentials are stored encrypted in Monte Carlo
- AWS Bedrock processes requests with no persistent storage
- Files uploaded to the Operations Agent or Support Agent are stored in Monte Carlo's AWS environment for up to 7 days
No model training: Customer prompts and responses are never used to train or fine-tune Monte Carlo's models or the underlying provider's general models. Models are used in pre-trained form via AWS Bedrock with no persistent storage at the provider, and this restriction is enforced contractually with Monte Carlo's AI partners.
Resilience, Provider Contingency, and Logging
Resilience and provider contingency. AI inference is accessed through AWS Bedrock, which abstracts the underlying model behind a managed AWS service and inherits AWS regional availability and redundancy. Monte Carlo's resilience posture for AI is graceful degradation using AWS-native tooling: because AI features are additive to core observability, a Bedrock disruption degrades AI-assisted features (for example, AI investigation and recommendations) but does not affect core monitoring, alerting, or lineage. Because Monte Carlo uses pre-trained models through Bedrock and does not fine-tune or retrain, a deprecated model or changed terms can be addressed by moving to an alternate Bedrock-hosted model without re-architecting.
Provider concentration. Monte Carlo deliberately standardizes on AWS Bedrock as the single inference gateway to keep customer data inside Monte Carlo's AWS environment under one consistent set of security and contractual controls, rather than fanning data out to multiple external AI vendors. Single-provider standardization on Bedrock is a recorded, accepted architectural decision; no multi-provider move is planned at this time. Alternative Bedrock-hosted models remain available as substitutes without exposing data to a new vendor or trust boundary.
Processing region and retention. AI processing occurs in the region where the customer's primary environment is deployed (US-East-1, EU-Central-1, or a customer-determined region on a dedicated DR tenant). Retention is standard and fixed as described in the Data Storage & Handling table above; custom logging retention is not an offering.
