The SF Database Meetup · Published 2026-09-04

Why your agent should manage it's context through SQL

Open on YouTube ↗

Summary

Overview

  • Speaker: Lewis Ellis
  • Channel: The SF Database Meetup
  • Main topic: Using SQL databases as context and memory backends for AI agents
  • Purpose: To convince developers that handing agents SQL and a database is an extremely powerful, effective, and simple way to handle agentic context, memory, and search. Lewis Ellis discusses the unreasonable effectiveness of giving AI agents a SQL tool to query databases for context and memory management, instead of relying on complex MCP servers, vector search, or file systems. He explores how schemas serve as the ultimate prompt engineering and tool design, how to do it safely with read replicas and role-based access, and why brute-forcing via SQL outperforms specialized multi-tool setups.

Topic Map

The Premise: Just Give Agents SQL

  • Explanation: Giving AI agents a single SQL query tool over a database containing all necessary application state, logs, and third-party data.
  • Key claims:
    • Agents do not need 20 different tools like markdown browsers, MCP servers, and grep tools.
    • A single SQL query tool can handle almost everything an agent needs.
    • Sql is universal, functioning like bash and grep.
  • Examples:
    • PostHog agent querying data
    • Conductor and YC DB giving agents SQL access
  • Terminology:
    • SQL tool
    • MCP server
    • Context window
    • PostHog
  • Why it matters: Simplifies agent architecture by replacing multiple custom tools with one universal querying interface.

Safety and Guardrails for Agent SQL

  • Explanation: Addressing the common fear that letting agents run arbitrary SQL is dangerous by implementing robust safety measures.
  • Key claims:
    • You can make agent SQL safe using read-only roles and read replicas.
    • Implement query limits such as row count limits and result set limits.
    • Use local config scoping and rolled-back transactions to restrict what tenants or tables an agent can query.
  • Examples:
    • Pointing Metabase at a read replica with timeouts turned down for data science teams
    • Postgres config scoping tables down to the specific querying tenant
  • Terminology:
    • Read replica
    • Read-only role
    • Audit logs
    • Transaction rollback
    • View scope
  • Why it matters: Mitigates security and performance risks associated with autonomous LLM-generated queries against production systems.

Why SQL Works So Well for Agents

  • Explanation: Explaining why LLMs excel at SQL generation and brute-forcing data retrieval compared to humans.
  • Key claims:
    • Agents know schemas better than any human developer.
    • Agents do not get tired of brute-forcing queries, joining tables, or reading hundreds of rows.
    • Model code files and schema definitions provide all necessary semantic context.
  • Examples:
    • Agents chaining 12 keywords together in a WHERE clause or reading through foreign keys across tables
  • Terminology:
    • Schema design
    • Brute-forcing
    • Semantic intent
  • Why it matters: Shifts the perspective on agent limitations: LLMs possess the grit and capacity to explore relational data in ways humans find tedious.

Tips, Tricks, and Context Assembly

  • Explanation: Practical techniques to optimize SQL usage for LLM agents, reduce token usage, and improve retrieval over time.
  • Key claims:
    • Have SQL tools return CSV instead of JSON to reduce token counts by half.
    • Schema design is tool design, prompt engineering, and context assembly all in one.
    • Define targeted curated views to shortcut complex multi-table joins for agents.
    • Audit log queries, metaprompt where it misses, and add successful queries to system prompts.
  • Examples:
    • Using DuckDB in between to connect agents to any data source
    • Streaming Slack messages into a database so agents never hit API rate limits
  • Terminology:
    • CSV serialization
    • Curated views
    • Metaprompting
    • DuckDB
    • System prompt
  • Why it matters: Provides actionable methods to make database-backed agent architectures efficient, scaleable, and self-improving.

Key Points

One tool beats twenty tools

  • Explanation: Providing agents with a single, universal tool like SQL is vastly superior to equipping them with numerous specialized tools and APIs.
  • Evidence: Similar to how code search shifted from complex vector tools back to grep, SQL acts as a universal code/data interface for agents.
  • Practical implication: Reduce tool bloat in agent frameworks by consolidating data access into a SQL interface.

Agents are exceptional at brute-forcing SQL

  • Explanation: Unlike humans who get frustrated by complex joins or large datasets, LLMs patiently iterate through queries, keywords, and foreign keys.
  • Evidence: Jeff Huber's quote: many gains of AI boil down to AI being better at brute forcing than humans.
  • Practical implication: Design schemas with rich context so agents can leverage their brute-force querying capabilities effectively.

Schema design is prompt engineering

  • Explanation: Investing time in clean database schemas, model files, and views directly improves agent performance without needing complex prompt hacks.
  • Evidence: Feeding database schemas and model files gives agents superior domain understanding.
  • Practical implication: Treat database schema design as a core component of your AI agent prompt engineering strategy.

Frameworks, Models & Processes

Agent SQL Context Pattern

  • How it works: Store all application data, logs, and third-party mirrors in a relational database, give the agent a read-only SQL tool with safety limits, and refine performance iteratively through audit logs and curated views.
  • Components:
    • Read-only database replica
    • SQL execution tool
    • Tenant view scoping
    • CSV result formatting
    • Audit logging and metaprompting loop
  • When to use: When building AI agents that need to search large corpuses of logs, transcripts, business data, or application state.

Examples & Case Studies

Replacing vector search with direct SQL queries over database tables in YC and Conductor applications.

  • Illustrates: Agents frequently reach for vector search when it fails to yield results, but perform much better when forced to write raw SQL queries.
  • Lesson: You probably don't need vector search; structured SQL queries often yield more precise retrieval outcomes for agents.

Streaming all Slack messages into a local database table instead of querying the Slack API.

  • Illustrates: Bypassing third-party API rate limits by mirroring external service data into a database.
  • Lesson: Keep mirrors of third-party APIs in your database so agents can query them locally via SQL without hitting rate limits.

Actionable Takeaways

  • Immediate:
    • Configure your agent SQL tools to return CSV instead of JSON to save token context.
    • Use read replicas and read-only roles to safely expose databases to agents.
    • Feed complete database schemas and model definition files to your agent.
  • Strategic:
    • Consolidate multiple specialized retrieval tools into a single SQL query interface.
    • Treat database schema design as prompt engineering and context assembly.
    • Mirror third-party API data into your database to avoid rate limits and unify agent context.
  • Questions to investigate:
    • How do schema size limits impact agent context windows on large enterprise databases?
    • What are the optimal query timeout and row limit thresholds for production agent SQL tools?

Claims Worth Verifying

  • Returning CSV instead of JSON from SQL query results cuts token usage in half for LLM agents. (technical efficiency claim)
  • Deleting vector search and relying solely on SQL queries improved agent retrieval accuracy in production. (architectural effectiveness claim)

Notable Quotes

"The unreasonable effectiveness of just putting everything in a database, and handing an agent a SQL tool!" (at 0:00) "Many of the gains of AI boil down to AI is better at brute forcing than you." (at 15:04) "One tool beats twenty. You already have Code Mode." (at 15:41) "Schema design is tool design, is prompt engineering, is context assembly." (at 17:16)

Compressed Summary

  • Give AI agents a single SQL tool over a database instead of 20 fragmented tools.
  • Ensure safety with read replicas, read-only roles, row limits, and transaction scoping.
  • Return SQL results as CSV instead of JSON to significantly reduce token consumption.
  • Treat database schema design, model files, and curated views as prompt engineering.
  • Keywords: sql, agents, database, context, schema
  • Core insight: Handing AI agents a single SQL query tool backed by a well-designed database schema provides superior, robust context management compared to complex multi-tool architectures.

Core insights

7
Mental Modelhigh noveltymoderate evidence

Schema design collapses four normally-separate engineering concerns into one artifact: the database schema simultaneously acts as the tool interface, the prompt, and the context-assembly layer for the agent.

Why it matters

It relocates a large fraction of agent-design effort from prompt hacking and tool plumbing into data modeling, which is a durable, testable artifact that version control and migration tooling already manage.

Generalization

Where an agent's primary interface is a structured query language, the data model becomes the primary prompt; improving schemas is a cheaper lever than improving prompt engineering.

Schema design is tool design, prompt engineering, and context assembly all in one.
Open source video
Treat database schema design as prompt engineering and context assembly.
Open source video
Mechanismhigh noveltymoderate evidence

Serializing SQL tool results as CSV instead of JSON roughly halves token consumption, because the result format itself is a context-cost variable independent of query correctness.

Why it matters

Result serialization is a cheap, global lever on context budget that applies to every query an agent issues, with no loss of retrieval logic.

Generalization

Tool output encodings should be chosen to minimize tokens per unit of semantic content, not for machine-parseability, since LLMs read results as text.

Have SQL tools return CSV instead of JSON to reduce token counts by half.
Open source video
Configure your agent SQL tools to return CSV instead of JSON to save token context.
Open source video
Architecturehigh noveltymoderate evidence

A single SQL tool can substitute for a large set of specialized retrieval tools (markdown browsers, grep, MCP servers), mirroring the earlier shift of code search from vector tooling back to grep.

Why it matters

Reducing tool count shrinks the surface an agent must reason about, cutting tool-selection errors and framework complexity at the same time.

Generalization

Universality of an interface (like bash/grep/SQL) can beat a federation of narrow, well-typed tools for agent use, because agents tolerate imprecise interfaces better than they handle tool-selection ambiguity.

Agents do not need 20 different tools like markdown browsers, MCP servers, and grep tools.
Open source video
A single SQL query tool can handle almost everything an agent needs.
Open source video
Sql is universal, functioning like bash and grep.
Open source video
Mental Modelhigh noveltymoderate evidence

Agents exploit brute-force querying as a capability: they will chain many WHERE-clause keywords, traverse foreign keys, and read hundreds of rows without fatigue, so schema design should optimize for agent-explorable structure rather than minimal query cost.

Why it matters

It inverts the human-centric instinct to pre-optimize queries and denormalize for efficiency; instead, richer relational structure and semantic context give the agent more surface to brute-force over.

Generalization

Where a human's cost function is query effort, an agent's cost function is context tokens and iterations — so designs that look wasteful to a human may be optimal for an agent.

Agents do not get tired of brute-forcing queries, joining tables, or reading hundreds of rows.
Open source video
Jeff Huber's quote: many gains of AI boil down to AI being better at brute forcing than humans.
Open source video
Agents know schemas better than any human developer.
Open source video
Practicemedium noveltymoderate evidence

Agent SQL access is made safe by layering database-native controls rather than application-level tool restrictions: a read-only role, a read replica, row/result-set limits, tenant-scoped config, and rolled-back transactions.

Why it matters

It pushes safety enforcement down to the database layer that already has the semantics for permissions, scoping, and timeouts, avoiding a custom policy layer in the agent harness.

Generalization

Guardrails for autonomous query generation belong in the data system's existing permission and resource-limit primitives, not in a bespoke intermediary.

You can make agent SQL safe using read-only roles and read replicas.
Open source video
Implement query limits such as row count limits and result set limits.
Open source video
Use local config scoping and rolled-back transactions to restrict what tenants or tables an agent can query.
Open source video
Practicemedium noveltyweak evidence

A closed improvement loop is proposed: audit the agent's SQL queries, metaprompt where it misses, and promote successful queries into the system prompt.

Why it matters

It turns query logs into a training/eval signal that progressively narrows the agent's search space without retraining the model.

Generalization

Observability data from agent tool calls can be fed back as prompt context, making the prompt a mutable cache of solved problems.

Audit log queries, metaprompt where it misses, and add successful queries to system prompts.
Open source video
Define targeted curated views to shortcut complex multi-table joins for agents.
Open source video
Architecturemedium noveltymoderate evidence

Mirroring third-party API data (e.g., Slack messages) into a local database table eliminates API rate limits and unifies agent-accessible state behind one interface.

Why it matters

It converts an external dependency with quotas and latency into a local, queryable, joinable dataset, broadening what the agent can correlate.

Generalization

For agent systems, ingestion-then-query generally beats live-fetch-then-respond when the data is reused across queries.

Streaming Slack messages into a database so agents never hit API rate limits.
Open source video
Mirror third-party API data into your database to avoid rate limits and unify agent co
Open source video

Deep dives

5

Schema-as-prompt: schema design as tool interface and context assembly

Research question

To what extent can schema design replace prompt engineering and tool interface design for SQL-native agents, and what schema features most improve agent query accuracy per token?

Why

If schema is the highest-leverage artifact, teams should shift agent-development effort from prompt hacks and tool plumbing to data modeling, versioned migrations, and curated views.

Schema design is tool design, prompt engineering, and context assembly all in one.
Open source video
Treat database schema design as prompt engineering and context assembly.
Open source video
Source video

Result serialization as context-cost lever: CSV versus JSON for agent SQL

Research question

How much do token counts and task accuracy change when SQL tool results are serialized as CSV versus JSON across wide, narrow, and nested result shapes?

Why

Serialization is a global, query-independent lever; if the claimed token reduction holds, it should be a default for tabular tool outputs.

Have SQL tools return CSV instead of JSON to reduce token counts by half.
Open source video
Configure your agent SQL tools to return CSV instead of JSON to save token context.
Open source video
Source video

Tool consolidation: one SQL interface versus many specialized agent tools

Research question

Does replacing specialized retrieval tools such as grep, markdown browsers, and MCP servers with a single SQL tool maintain or improve agent task success, tool-selection accuracy, and latency?

Why

Tool sprawl increases selection ambiguity and framework complexity; evidence for a universal SQL interface would justify simplifying agent architectures.

Agents do not need 20 different tools like markdown browsers, MCP servers, and grep tools.
Open source video
A single SQL query tool can handle almost everything an agent needs.
Open source video
Sql is universal, functioning like bash and grep.
Open source video
Source video

Database-native guardrails for autonomous SQL agents

Research question

What is the minimal combination of read-only role, read replica, row limits, result-set limits, tenant-scoped config, and rolled-back transactions that makes agent SQL safe without excessive capability loss?

Why

Safety enforcement in database primitives could centralize policy and enable autonomy, but coverage and blocked-query rates are unmeasured.

You can make agent SQL safe using read-only roles and read replicas.
Open source video
Implement query limits such as row count limits and result set limits.
Open source video
Use local config scoping and rolled-back transactions to restrict what tenants or tables an agent can query.
Open source video
Source video

Audit-log metaprompting: scaling and staleness of promoted SQL queries

Research question

How does promoting successful SQL queries from audit logs into the system prompt affect agent accuracy, context consumption, and solution diversity as promoted queries accumulate?

Why

The proposed improvement loop lacks pruning or decay; without measurement it may bloat context and ossify agent behavior.

Audit log queries, metaprompt where it misses, and add successful queries to system prompts.
Open source video
Define targeted curated views to shortcut complex multi-table joins for agents.
Open source video
Source video

Article ideas

4

Your Schema Is Your Prompt: Agent Design Moves into the Data Model

For SQL-native agents, schema design is not just database engineering; it is simultaneously tool design, prompt engineering, and context assembly, so teams should invest in data modeling and curated views rather than bespoke prompt plumbing.

Angle

Argue that agent builders should treat schema migrations, views, and semantic table design as their primary prompt-engineering surface, with worked examples of schema choices that change agent behavior.

Source video

CSV Is an Agent Interface: The Hidden Token Budget in Tool Output

Tool result serialization is a first-class context-engineering decision; for tabular SQL results, CSV often halves token consumption versus JSON and should be the default output format for agent tools.

Angle

Quantify and explain why CSV wins for LLM-readable tabular data, show where JSON remains necessary for nested structures, and provide implementation patterns for CSV-emitting SQL tools.

Source video

One Tool to Query Them All? The Case Against Agent Tool Sprawl

A single universal SQL tool can replace many specialized retrieval tools; reducing tool count lowers tool-selection errors and framework complexity, following the same arc as code search returning to grep.

Angle

Contrast multi-tool agent stacks with a single SQL interface, examine when universality beats narrow tools, and discuss failure modes where SQL is not enough.

Source video

Safe Autonomy: Agent SQL Should Be Governed by the Database, Not the Harness

Agent SQL safety is better enforced through database-native primitives such as read-only roles, read replicas, row limits, tenant-scoped config, and rolled-back transactions than through custom application-level allow-lists.

Angle

Argue for pushing guardrails down into the data platform, show how existing permissions and resource limits can be reused across agents and humans, and identify remaining risks.

Source video

Project ideas

4

Guardrail Red-Team for Autonomous SQL Agents

gatehouse

A minimal database-native guardrail set (read-only role, read replica, row limit, tenant-scoped rollback) blocks unsafe or resource-exhausting agent-generated SQL with less than 5% task-capability loss compared to an unguarded baseline.

Proof of concept

Build an agent SQL harness over a Postgres read replica with configurable guardrails; run a red-team suite of write, cross-tenant, expensive, and prompt-injected queries alongside a task benchmark; toggle individual guardrails to measure coverage and capability impact.

Measurement

Unsafe query block rate, cross-tenant leakage incidents, query runtime and row-count enforcement rate, and task success rate versus unguarded baseline.

Source video

Schema-Ablation Context Benchmark

beyond-evals

Full DDL plus curated views yields higher agent query accuracy per token than table-name-only or partial schemas; token savings from schema truncation do not compensate for accuracy loss.

Proof of concept

Create a realistic multi-table database; run an agent against schema variants including full DDL, table names only, curated views, and column subsets on a fixed retrieval task set; record accuracy and prompt and completion token usage.

Measurement

Task accuracy, tokens consumed per correct answer, query error rate, and number of agent iterations across schema conditions.

Source video

SQL versus Vector Retrieval Head-to-Head

beyond-evals

On structured tabular corpora with explicit joins, agent SQL beats vector search on retrieval precision and token cost; on unstructured text corpora, vector search wins.

Proof of concept

Construct paired corpora: one relational and tabular, one unstructured text; run the same retrieval questions through an SQL-querying agent and a vector-RAG agent; compare outcomes.

Measurement

Retrieval precision and recall, answer accuracy, tokens per query, latency, and failure-case categories.

Source video

CSV versus JSON Tool-Output Benchmark

beyond-evals

CSV serialization reduces tokens by at least 40% versus JSON on wide and narrow tabular SQL results without lowering task accuracy; nested result sets reduce or reverse the advantage.

Proof of concept

Wrap one SQL execution tool with switchable CSV and JSON serializers; run identical agent retrieval tasks over wide, narrow, and nested result shapes; measure tokens, accuracy, and latency.

Measurement

Token count ratio CSV to JSON, task accuracy, latency, and error rate from malformed or truncated outputs.

Source video

Architectural implications

4

Retrieval logic is pushed from an application tool layer into database views and schema.

Before

Engineers build bespoke retrieval tools, MCP servers, and vector indices to serve the agent.

After

Engineers define curated views and rich schemas in the database; the agent queries them directly.

Consequence

Retrieval behavior becomes a data-migration/versioning concern rather than an application-code concern, and knowledge of what to retrieve is expressed declaratively.

Source video

Context assembly moves from prompt-construction code into the database and result formatting.

Before

Application code assembles context by fetching and formatting data before the model call.

After

The agent decides what to fetch and receives CSV rendered directly from query results.

Consequence

Context window composition becomes a runtime, agent-directed process, making token budget a function of query design and serialization format.

Source video

Third-party integrations shift from live API calls at query time to periodic mirrors in the database.

Before

Agent calls external APIs (Slack, etc.) at inference time, subject to rate limits and latency.

After

External services stream into local tables the agent queries with SQL.

Consequence

Rate limits and API availability are decoupled from agent execution, and external data becomes joinable with internal state.

Source video

Safety enforcement moves from agent-harness restrictions to database role and resource primitives.

Before

Guardrails implemented as custom validation/allow-listing inside the agent tool wrapper.

After

Read-only roles, read replicas, and rolled-back, tenant-scoped transactions enforce limits.

Consequence

Safety policy is centralized in the data platform and reused across agents and human users alike.

Source video

Tradeoffs and failure modes

4

Autonomous SQL against production data

Benefit

Single universal interface replaces many specialized tools, simplifying agent design.

Cost or risk

Arbitrary LLM-generated queries can be unsafe or expensive; the summary explicitly frames this as a common fear requiring mitigation.

Addressing the common fear that letting agents run arbitrary SQL is dangerous by implementing robust safety measures.
Open source video
Source video

Agent brute-forcing queries

Benefit

Agents will iterate over joins, keywords, and foreign keys without fatigue, potentially yielding better retrieval.

Cost or risk

Unbounded iteration and row-reading implies additional query volume, compute, and token cost per answer.

Agents do not get tired of brute-forcing queries, joining tables, or reading hundreds of rows.
Open source video
Source video

Metaprompting from audit logs

Benefit

Successful queries added to system prompts and curated views shorten future search.

Cost or risk

Accumulating queries in the system prompt consumes context and may ossify the agent around past solutions; the summary offers no evidence of limits or decay handling.

Audit log queries, metaprompt where it misses, and add successful queries to system prompts.
Open source video
Source video

Replacing vector search with SQL

Benefit

Structured SQL queries often yield more precise retrieval outcomes for agents.

Cost or risk

This is a strong contrarian claim whose boundary conditions (unstructured corpora, semantic similarity) are not addressed in the summary.

You probably don't need vector search; structured SQL queries often yield more precise retrieval outcomes for agents.
Open source video
Source video

Open questions

5

Under what retrieval conditions does raw SQL outperform vector search for agents?

Why unresolved

The summary asserts better outcomes on YC/Conductor applications but gives no benchmark, corpus characteristics, or failure conditions.

Research direction

Build a head-to-head retrieval benchmark on the same corpus comparing agent-SQL vs vector search on precision, latency, and token cost.

Source video

How does the audit-log/metaprompting loop scale before the system prompt becomes bloated or stale?

Why unresolved

The loop is described as a practice but with no limits, pruning strategy, or evidence of sustained gains.

Research direction

Measure agent accuracy as promoted queries accumulate in the system prompt; test pruning and retrieval-of-past-queries instead of static insertion.

Source video

What is the minimum schema/tool output needed to keep agent queries correct without inflating context?

Why unresolved

The summary recommends feeding complete schemas and model files but does not quantify the context cost or accuracy trade-off of partial schemas.

Research direction

Ablate schema detail (full DDL vs table names only vs curated views) and measure query accuracy and tokens.

Source video

What is the minimal guardrail set that makes agent SQL safe without crippling capability?

Why unresolved

Multiple controls are listed (read replica, read-only role, row limits, tenant config, rollback) but no evaluation of coverage or of queries they block.

Research direction

Red-team an agent SQL harness against documented limits to find which guardrail combination blocks unsafe queries with least capability loss.

Source video

Does the CSV-vs-JSON token reduction hold across result shapes and models?

Why unresolved

The claimed ~half reduction is stated without benchmark detail or dependence on result structure.

Research direction

Token-count and task-accuracy benchmark of CSV vs JSON serialization across wide, narrow, and nested result sets.

Source video

Key claims

8
comparativeVerification needed

Agents do not need many specialized tools; a single SQL query tool covers almost everything.

Evidence

Agents do not need 20 different tools like markdown browsers, MCP servers, and grep tools.

Question

Does consolidating to one SQL tool maintain task success versus a multi-tool baseline on the same benchmark?

Source video
factualVerification needed

Returning results as CSV instead of JSON halves token counts.

Evidence

Have SQL tools return CSV instead of JSON to reduce token counts by half.

Question

What is the measured token ratio for CSV vs JSON across representative result sets?

Source video
opinionVerification needed

LLMs are better than humans at brute-forcing data retrieval.

Evidence

Jeff Huber's quote: many gains of AI boil down to AI being better at brute forcing than humans.

Question

Is there a measured comparison of agent vs human query iteration quality and depth?

Source video
causalVerification needed

Agent SQL can be made safe with read-only roles and read replicas.

Evidence

You can make agent SQL safe using read-only roles and read replicas.

Question

Do read-only roles plus replicas eliminate write and resource-exhaustion risks from agent-generated queries in practice?

Source video
comparativeVerification needed

Structured SQL queries often yield more precise retrieval outcomes than vector search for agents.

Evidence

You probably don't need vector search; structured SQL queries often yield more precise retrieval outcomes for agents.

Question

On what corpus types does SQL retrieval match or beat vector search, and where does it fail?

Source video
opinionVerification needed

Agents know schemas better than any human developer.

Evidence

Agents know schemas better than any human developer.

Question

Does schema-grounded agent reasoning actually exceed expert humans on schema-dependent retrieval tasks?

Source video
causalVerification needed

Mirroring external API data into a local database prevents API rate-limit failures.

Evidence

Streaming Slack messages into a database so agents never hit API rate limits.

Question

What freshness, storage, and synchronization costs accompany API-to-database mirroring at scale?

Source video
factualVerification needed

Queries can be restricted by tenant using local config scoping and rolled-back transactions.

Evidence

Use local config scoping and rolled-back transactions to restrict what tenants or tables an agent can query.

Question

Does per-query config scoping hold under concurrency and prevent cross-tenant leakage?

Source video

Connections

5