Agent-Based Workflow Automation in Spreadsheets for Non-Technical Users

otto · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.2 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Spreadsheet workflow automation

Otto needed to make agent workflows usable by non-technical business users through a familiar spreadsheet interface.

Constraints:

• Non-technical users
• Structured outputs
• Dependency handling across cells
• Model cost/performance selection

Architecture

Otto embeds agents into a spreadsheet-shaped workflow instead of making users operate a chatbot or database. Users place unstructured data into spreadsheet cells; each cell can act as an agent that performs a task; columns can wait for earlier columns to finish before running downstream tasks; outputs land in tables that finance and accounting users already understand. Behind that interface, Otto routes work across a three-tier model strategy: cheap workhorse models for grunt work, middle-tier fast smart models for most tasks, and heavy reasoning models for the hardest long-running work, with evals and customer usage guiding model placement.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  unstructured-input-data[Unstructured input data] --> spreadsheet-interface[Spreadsheet interface]
  spreadsheet-interface --> cell-agents[Cell agents]
  cell-agents --> column-dependency-scheduler[Column dependency scheduler]
  cell-agents --> model-router[Model router]
  model-router --> workhorse-models[Workhorse models]
  model-router --> middle-tier-models[Middle-tier models]
  model-router --> heavy-reasoning-models[Heavy reasoning models]
  evaluation-loop[Evaluation loop] --> model-router
  column-dependency-scheduler --> tabular-outputs[Tabular outputs]

Components

Data flow

A non-technical user puts unstructured data into a spreadsheet. Cell-level agents process tasks, columns wait on dependencies, outputs are written back to tabular cells, and Otto selects an appropriate model tier based on intelligence, price, latency, and task difficulty. New models are evaluated through internal evals, community signal, and customer usage.

Why this architecture

Otto chose spreadsheets because business users already rely on Excel-like interfaces, while engineers' preferred JSON/database abstractions are alien to many finance and accounting workflows. The tiered model architecture keeps agents affordable and responsive by avoiding heavy reasoning models for simple extraction tasks.

Models used: Gemini Flash · Claude 3.7 · o1 Pro

Scale

• The source emphasizes accountants and finance teams as users who spend many hours in spreadsheets.
  “the average accounting team or finance or whatever, like they're in that spreadsheet, you know, many, many, many hours in the day.”transcript, implied
• Otto's model strategy is dynamic as model capability, price, and latency shift.
  “I'll constantly try to categorize, okay, what is where, you know, what model goes where. And that's kind of how it gives me a good signal to like determine where to use a model, how to use it, when to use it.”transcript, stated

Alternatives considered (roads not taken)

Chatbot-only agent interface

Rejected because: Otto wanted agents to run in the tabular interface business users already understand.

Always use the strongest model

Rejected because: Latency and cost make heavy reasoning models a poor fit for many routine tasks.

Patterns

tool-use-orchestration (workflow)

Spreadsheet cells become agentic task units that execute business workflows.

model-routing (model-operations)

Otto uses model tiers to balance cost and task difficulty.

Tradeoffs

How to expose agents to business users.

Chose spreadsheet UX over chatbot-only interface.

Rationale: The summary says the familiar spreadsheet UX lets finance/accounting users harness agents without technical expertise.

How to expose agents to non-technical users.

Chose cell-level agents inside spreadsheets over a chatbot or database-style agent interface.

Rationale: The spreadsheet lets agents fit the business-user workflow instead of forcing users into technical abstractions.

How to route tasks across models.

Chose three tiers by cost, latency, and reasoning need over one default frontier model for everything.

Rationale: Routine work should use cheap models, while expensive reasoning models are reserved for difficult tasks.

Evaluation

Otto evaluates model choices through customer usage patterns and iterative model testing.

Metrics: usage patterns · model test results

Outcomes

• The case describes broader accessibility of agent workflows for non-technical users.

No hard adoption metric is provided in the summary.