Our CEO walks into an AE meeting on a Monday morning. She opens Slack, types a question to our internal agent: “What are the top objections from New York districts this quarter?” Thirty seconds later she has a sourced answer pulling from Salesforce notes, support tickets, and call transcripts. No dashboard. No data request. No analyst. That’s a regular morning at Parallel Learning. I’ve written about why AI adoption needs an executive sponsor, why the real bottleneck is information transit rather than individual speed, and why lean teams need full-stack builders. This article is about what we actually built. An internal AI agent called Voltaire connects our entire knowledge surface and makes it conversational. The arguments I made in those pieces? This is the implementation behind them. Parallel Learning is a venture-backed healthcare and ed-tech company delivering licensed special-education services to school districts across the US. We’re small, a few dozen people, running a proprietary telehealth platform called Pathway. Our data lives in BigQuery. Documents are scattered across Google Drive. Support tickets sit in Zendesk. Engineering work is tracked in Linear. Meeting transcripts pile up in Drive. The codebase is navigable by three developers. Every department had the same complaint, phrased differently. Revenue couldn’t get territory data without a data pull. Operations couldn’t answer edge-case questions without pinging a senior team member. Leadership couldn’t review customer health without sitting through account meetings. The information existed. Getting to it always required a human intermediary. The transit cost was brutal. Not because anyone was slow, but because every question required routing through someone else’s calendar. Voltaire is a Slack bot. Any employee mentions it in a channel or sends it a direct message, and it responds in-thread with a sourced answer. That’s the interface. Nothing to install, nothing new to learn, no dashboard to bookmark. Calling it a bot undersells the architecture, though. Voltaire is an agentic system. When it receives a question, it doesn’t pattern-match against a FAQ or retrieve the nearest document chunk. It plans which data sources are relevant, dispatches specialized agents to query them, pulls the results together, and formats a response with citations. A single question might trigger a SQL query against our data warehouse, a search through our knowledge graph, and a ticket retrieval from Zendesk, all in one turn. The architectural choice that matters most: the orchestrator doesn’t see the internals of each agent. It calls query_bigquery and gets back a finished result. The BigQuery agent handles table discovery, SQL generation, error recovery, and PII filtering on its own. The orchestrator stays clean. That isolation is how we add new data sources without rewriting the reasoning layer. Voltaire is explicitly not customer-facing and not clinical. Internal knowledge only. That boundary matters because it lets us give the agent broad access to company data without the liability surface of a customer-facing product. The value of a company brain isn’t any single data source. It’s reasoning across all of them in one turn. The data warehouse is the most valuable source. Revenue metrics, student outcomes, operational KPIs, financial data, CRM records mirrored from Salesforce, and data piped in from every other internal tool we run. The BigQuery agent translates natural language into SQL, finds the right tables from a documented catalog, writes the query, and self-corrects if the SQL fails. “What’s our net revenue retention for districts that renewed in Q1?” gets a grounded number, not a hallucinated estimate. The document layer is where scale gets interesting. We have over 250,000 files across Google Drive and Zendesk, and that’s just external-facing knowledge, not even counting internal documents. PDFs, slide decks, SOPs, policy documents, knowledge base articles. These aren’t dumped into a vector database and left to rot. They’re crawled into an offline knowledge graph: an SQLite snapshot with full-text search, classification tags, AI-generated summaries, similarity edges, and per-user access controls. When the agent searches for “our onboarding SOP for new providers,” it’s querying a curated, classified, permission-aware index. Not running a naive similarity search over raw embeddings. Support tickets give operational intelligence. “What are the top issues from California districts this month?” pulls from Zendesk ticket history and finds patterns across hundreds of conversations. Linear and the codebase answer product and engineering questions from source, not from someone’s recollection of last sprint’s decisions. Every meeting transcribed via Gemini gets stored in Drive and indexed. Six months of transcripts creates a searchable institutional memory that no wiki can replicate. Wikis capture decisions. Transcripts capture the reasoning behind them. If the agent gives a bad answer three times, nobody comes back. Trust compounds slowly and collapses fast. You don’t get to iterate your way to adoption when the first impression is a hallucinated revenue number that someone drops into a board deck. We learned this early and designed for it at every layer. Every response includes sources. SQL queries are visible so you can verify the logic. Document references link directly to Google Drive. If the agent cites a Zendesk article, you can click through and read it yourself. Transparency isn’t something we bolted on after launch. It’s the reason people kept using it past the first week. When a question touches restricted data — student PII, sensitive HR information — the agent doesn’t just refuse. It explains what it can’t access and proposes a safe reformulation. “I can’t show individual student names, but here’s the same analysis using anonymized IDs.” A hard refusal with no path forward trains people to stop asking. A refusal with a reformulation trains people to ask smarter questions. The knowledge routing layer is where trust lives architecturally. Before the orchestrator runs, a lightweight planner decides which knowledge articles to inject and which agents to activate. Bad tool selection produces bad answers regardless of how capable the model is. Send a revenue question to the codebase agent instead of the BigQuery agent, and no amount of reasoning saves the response. Getting the routing right matters more than picking the best model. The CEO no longer opens Salesforce dashboards. She asks Voltaire for objection patterns across territories before an AE meeting and gets a sourced answer in thirty seconds. That’s not a faster version of the old workflow. It’s a different workflow, one where leadership can self-serve operational intelligence without a meeting or a data request. Our support ops manager was the biggest AI skeptic in the company. After a shadow session where we sat with her and showed how voice-to-text could replace her manual SOP writing, she started building her own workflows. Within weeks she was giving a company-wide presentation on what she’d automated. Voltaire now answers her team’s edge-case questions from the knowledge base. Those questions used to land in a senior staff member’s DMs. A phishing incident hit our BDR team. Investigating it meant reconstructing a timeline: which links were clicked, which IP addresses showed up, whether forwarding rules had been planted, whether OAuth grants needed cleanup, whether devices were compromised. Manual forensics would have taken a full day. With an AI-assisted workflow pulling from Google Workspace audit logs, it took an hour. Our head of business development came back from a conference with an attendee list. 280 names, no contact details, no CRM mapping. Someone doing this manually spends days cross-referencing LinkedIn, company websites, and Salesforce. Voltaire checked which names already existed in Salesforce, ran parallel lookups for contact information, verified the results, and dropped enriched records into a shared sheet. Minutes instead of days. Voltaire took two and a half weeks to build. The data infrastructure underneath it took two years. This is the part that doesn’t demo well. ETL pipelines feeding into BigQuery from every operational system: Salesforce, Zendesk, and a dozen other internal tools. dbt transformations that normalize and document the data. Column-level descriptions for every table in the warehouse, because an AI agent that doesn’t know what a column means will write SQL that looks right and returns wrong numbers. The knowledge graph deserves its own article, and it’ll get one. Short version: we crawl every Google Drive shared drive and personal drive using domain-wide delegation, resolve Google Group memberships into per-email access controls, classify over 250,000 files with AI-generated tags, build search summaries and similarity edges, and package everything into a versioned SQLite snapshot that Voltaire loads at startup. The agent can only see files that the requesting user has permission to access. That check runs in real time, resolved from the same HR data that feeds our RBAC system. None of the AI layer works without the data layer underneath it. An LLM with access to an undocumented, inconsistently named data warehouse will generate confident SQL that returns wrong numbers. An LLM searching an uncurated document dump will retrieve irrelevant chunks and hallucinate connections between them. The boring infrastructure is the entire moat. Not Voltaire. Not yet. Build the data layer. Get your operational systems feeding into a central warehouse. Document your schemas — column-level descriptions, not just table names. Start transcribing meetings and storing them somewhere searchable. Every month of centralized data you collect now is context you can’t backfill later. Start with a single agent that answers questions from one data source well. Natural language to SQL against your warehouse is the highest-ROI starting point because the data is structured and the answers are verifiable. If the SQL returns the wrong number, you can see why. That debuggability builds trust before you expand. Then add document retrieval. Then tickets. Then code. Each source compounds the value because the orchestrator can reason across all of them. A question that touches revenue data and support tickets and a knowledge base article gets an answer that no single-source system could produce. The mistake I see most often is building a chatbot wrapper around an LLM with no grounded data. You get confident answers with no relationship to reality, and you burn the trust you need for the version that actually works. The other mistake is waiting until the data is “ready.” It won’t be. Start collecting now, start documenting now, and build the AI layer on whatever foundation you have. You can improve data quality while building the agent. You can’t build the agent on data that was never collected.
