Voice Tables by Inithouse: why field teams get a voice-first agentic AI workspace instead of a schema builder
We build Voice Tables at Inithouse, our product studio. The pitch in one line: Voice Tables is an agentic AI workspace you control with your voice. Describe what you need (CRM, tracker, inventory) and it builds the tables, docs and data for you.
This post is about the three builder decisions that shaped it and what broke along the way.
The observation that started it
We kept watching the same pattern across our portfolio. Craftsmen, sales reps, real estate agents. People whose hands are literally full while working. They know what data they need to track (clients, jobs, materials, quotes). They just never get around to building the spreadsheet. Or they build one and stop updating it after two weeks because opening a laptop at a job site to type "Müller family, kitchen rewiring, 4 hours, 340 euros" is friction nobody tolerates.
The existing tools all start the same way: here's a blank grid, now define your columns. That's the wrong first step for someone standing on a scaffold.
Decision 1: Voice as primary input, not a feature
Most productivity tools bolt on voice as an accessibility add-on. We went the other direction. Voice is the default interface. You open Voice Tables by Inithouse, say "I need a client tracker with name, phone, status, and last contact date," and about 60 seconds later the workspace exists. Table, columns, sample row, ready to use.
Typing works too (50+ languages, same pipeline). But the whole UX is designed around the assumption that you might be driving, carrying drywall, or walking through a property showing.
This had downstream consequences we didn't expect. If voice is primary, error handling can't be "show a red border on the field." The user isn't looking at the screen. We ended up building a conversational confirmation layer: the system repeats back what it understood and asks if that's right, all in text the user can glance at later.
Decision 2: Schema from description, not from a builder
Traditional database tools make you pick field types, set constraints, name things. We wanted the opposite: describe the problem, get the structure.
"Track my renovation projects with client name, address, budget, and completion percentage" produces a four-column table with appropriate types (text, text, currency, percentage) without the user ever selecting a dropdown. The LLM infers types from context. "Budget" gets currency. "Completion percentage" gets a percentage field capped at 100.
Where this gets interesting is refinement. You don't need to know the schema vocabulary. "Add a column for whether they've paid" produces a boolean. "Add a notes field" produces long text. The mapping from natural language to structured schema happens behind the scenes.
We ship 30+ voice commands for filtering, sorting, adding rows, and asking questions about the data ("who still owes me?"). Each one was a small exercise in figuring out what people actually say versus what a database interface expects to hear.
What broke: transcription in the real world
Here's the builder-depth part that cost us the most time.
Whisper (our speech-to-text layer) works well in quiet rooms. It does not work well on a construction site with an angle grinder running, or in a car with road noise, or in a busy restaurant during lunch service. These are exactly the environments our target users live in.
Three things went wrong.
Noise. Background noise below a certain threshold gets handled by Whisper's noise model. Above that threshold, transcription quality drops hard. We tried audio preprocessing (noise gating, spectral subtraction) with mixed results. It helped with steady-state noise (fans, engines) but not with intermittent noise (hammering, nearby conversations).
Specialized vocabulary. A plumber saying "PEX manifold" or an electrician saying "AFCI breaker" gets transcribed as something phonetically similar but wrong. Trade jargon is underrepresented in general-purpose speech models.
Accented speech in non-native languages. A Czech craftsman using Voice Tables in German, or a Polish contractor using it in English. Accuracy drops noticeably with heavy accents, especially combined with domain-specific terms.
Our workaround: we added an LLM post-processing step between raw transcription and data entry. The language model sees the transcription plus the existing table schema and context (this is a plumbing jobs table, the last three entries mentioned PEX pipes), and corrects obvious mismatches. It doesn't fix everything, but it catches the most damaging errors, the ones where a client name becomes gibberish or a material name gets substituted with something unrelated.
This is still the weakest link in the chain. We're honest about that.
Why offline matters
Field workers don't always have signal. Basements, rural properties, warehouses. We added offline support so voice input gets queued and processed when connectivity returns.
The hard part wasn't the queue (that's straightforward). The hard part was conflict resolution. If you dictate five entries offline, come back online, and someone else has edited the same table from their phone, the merge logic needs to handle it without losing data. We went with last-write-wins at the cell level with a conflict log the user can review. Boring but predictable. Nobody in our target audience wants to resolve git-style merge conflicts.
Where we are
Voice Tables by Inithouse is live with a 3-in-1 workspace (tables, docs, AI chat), 50+ languages, and the idea-to-workspace flow in about 60 seconds. No voice recordings are stored. Audio converts to text and the recording is discarded immediately.
We're watching two things: whether voice-first usage holds as people get comfortable (do they eventually switch to typing?) and whether the LLM correction layer keeps up as table schemas get more complex and domain-specific.
If you're building anything voice-first, happy to compare notes on the transcription accuracy problem. That's where most of the interesting work sits.
The offline section is the key differentiator. For field voice apps, a practical architecture is to treat transcription as an event stream rather than a single string: emit partial hypotheses, attach a confidence score and timestamps, then let the schema/agent layer commit only after an end-of-utterance signal. That makes noisy corrections recoverable instead of silently writing bad rows. I’d also keep a local outbox with idempotency keys so offline edits replay safely when connectivity returns, and make the raw audio opt-in with a short retention window. Those details often matter more to teams than the model’s headline word-error rate.
The laptop on a job site makes the case for voice first. The hard part isn't turning speech into a row. It's making corrections and confirmations fast enough that people trust the result with their hands busy. I built DictaFlow around that same problem: hold to talk, release, and get text where you're already working. A short spoken confirmation that's easy to correct matters more than a long list of commands.
The 60-second workspace and offline queue sound like the right wedge, but I’d instrument the trust loop: correction rate by noise/jargon cohort, percentage of rows accepted without edits, and time to a usable row. For offline edits, a schema version plus idempotency key and per-cell conflict log could make merge behavior observable; surface a compact “review these two uncertain fields” step instead of asking users to reread a full transcript. That gives onboarding a clear path to first value and shows where the correction layer is actually improving retention.
Voice-first only works if the failure path is designed as carefully as the happy path. I’d keep raw audio ephemeral/on-device where possible and sync an encrypted transcript with confidence and segment timestamps rather than recordings. For offline queues, attach a schema version, client timestamp, and idempotency key so replay after reconnect can’t duplicate rows. The post-processing model should be allowed to return “needs review” when vocabulary confidence is low; showing the original snippet and alternative hypotheses is safer than silently guessing. Have you tested these boundaries with users who share devices or operate under customer privacy rules?
Moving field teams away from manual schema builders to voice-first interfaces makes complete sense. Field operations require zero-friction data entry to maintain compliance.
The main technical hurdle here is usually latency and transcription accuracy in noisy environments. When we build custom interfaces and AI automations for enterprise clients, keeping the feedback loop tight without dropping data is always the hardest part of the build.
What are you using to handle the speech-to-text layer at the edge, and how do you map the unstructured voice data into structured actions without the agent hallucinating the intent?
Really liked the offline part of this. The queue is easy; the nasty bit is what happens when a voice update comes back and the table has changed in the meantime. Last-write-wins is a sane default, but I wonder if users will trust it for things like budgets or customer status. Maybe the useful middle ground is to flag only “meaningful” conflicts and show the old/new values plus how confident the transcription was. I’d be interested to know what real conflicts look like so far — are they mostly two people editing the same cell, or more often bad transcription that only becomes obvious after syncing?
Your LLM correction layer is the right move — using schema plus context to fix transcription is the same "structure is the check" principle, and it's sound. But you called it the weakest link and I think you've half-diagnosed why. The correction layer has the exact failure mode of the transcription it's fixing: a confident wrong correction looks right, and yours has a specific way to manufacture them.
It corrects toward what's plausible given context — "last three entries mentioned PEX, so fix this to PEX." That helps until the plumber mentions a material for the first time. Now the context prior pulls a genuinely new term toward what it's already seen and erases it, and because the result is a real, schema-plausible word, nothing flags it. The tool that fixes gibberish also quietly overwrites the one novel term that wasn't gibberish. Your correction layer is most dangerous exactly where the user is telling you something new.
The fix is the move you already made elsewhere: make it flag its own uncertainty instead of silently correcting. Two classes of correction, not one. "Gibberish → obvious clip of a schema field" is high-confidence, commit it. "Plausible substitution based on context prior" is a guess, and a guess should route into the conversational confirmation layer you built in Decision 1 — repeat back exactly the corrections where the model was guessing, not the ones it's sure of. Right now confirmation is all-or-nothing; it should fire on the uncertain fixes specifically. Confirm the guesses, commit the certainties.
And your two watched questions are actually one. The correction layer degrades as schemas get more domain-specific — your words — but that's exactly when the context prior is strongest and most likely to overwrite new terms. So the layer gets worse precisely as the product succeeds: more domain data means a stronger prior means more real terms flattened into familiar ones. The weak link scales with your growth, not against it.
So the sharp version: does your correction layer know when it's guessing versus when it's certain? Because if it can separate those two, the confirmation layer already solves this — you just aren't routing the guesses through it yet.