AI agents are most useful when they move data between separate applications, especially when they can extract structure from emails and other unstructured sources.
2
AI integrations should be designed around the actions models naturally perform, with abstractions such as "add a table" instead of difficult low-level API operations.
3
Long-running AI work needs persistent state, sandbox security, progress feedback, cost estimates, and opportunities for human review before large jobs continue.
Summary
Jiquan Ngiam describes Lutra as an AI agent that completes work across email, spreadsheets, CRM systems, and other applications. He focuses on ordinary jobs such as extracting invoice details, filling missing spreadsheet fields, and researching many accounts. These tasks work because AI can interpret unstructured information and connect software that was built in separate silos. Ngiam argues that integrations should use abstractions suited to models. A model should be able to add a table rather than reconstructing the low-level Google Docs API steps. He also explains why code-based agents can scale repeated work better than making one model call per row. The hard engineering problems include secure sandboxes that can reach external systems, persistent state, live progress updates, and warnings about time and cost. Looking ahead, he expects cheaper models and larger context windows to support more agentic systems. He also imagines software that changes its interface around the user's task and taste.
Useful agents start with ordinary work across disconnected applications
Ngiam says Lutra users mainly want AI to pass emails, read invoices, and put Airtable or spreadsheet data into shape. The reliable pattern is data moving from one system to another, with AI extracting or transforming it along the way. His example takes invoice emails, extracts line items, and puts them into accounting software or a spreadsheet. Another workflow reads a signup sheet, drafts messages asking people for missing details, extracts information from their replies, and writes it back into the sheet. These are familiar ETL processes, except the source may be unstructured email and the agent can work across applications.
Integrations should expose actions at the level models can use
Ngiam says conventional APIs were designed for developers who can handle error codes and deterministic steps. AI models need an intermediate abstraction between point-and-click interfaces and raw APIs. Adding a table to a Google Doc illustrates the problem. The low-level API requires engineers to create the table and work out how to fill each cell, which is difficult for a model. Lutra instead aims to expose an action such as adding a table, while the integration handles the implementation. Ngiam says the team also asks what action the model itself would prefer, then shapes the interface around that tendency.
Better abstractions can remove recurring model errors
Spreadsheet updates show why interface design affects reliability. If a model receives a function that updates a cell by coordinates, it can make off-by-one mistakes because of header rows. Ngiam says a better action accepts a row as input and lets the model identify columns by their headers. That makes the original error harder to produce. His broader rule is to observe what the model is trying to do. If the behavior is reasonable, the system should often be redesigned to support it instead of adding another instruction that fights the model.
Guardrails should be tested against model behavior
Lutra uses generated code so it can apply familiar programming checks, including type checking. The model can produce code, the system can check whether values have compatible types, and the model can revise the code when they do not match. Ngiam also gives a limit to this approach. Python type checkers may reject variable shadowing, while models commonly produce that pattern. If a rule repeatedly causes problems and is not essential, he would remove it while keeping the rules that matter. He says changing the system to accept useful model behavior has worked better than repeatedly expanding the prompt.
Code-based agents scale repeated work more efficiently
Ngiam contrasts ReAct, where a model repeatedly calls functions, with CodeAct, where it writes code and runs it. CodeAct lets an agent write a function for one spreadsheet row, show the result for review, and then add a loop over many rows. That can take a small number of model interactions. With a function call per row, a job involving thousands of rows would require a model interaction for every row and become much more expensive. He says this pattern fits tasks such as researching accounts, collecting information, scoring candidates, and writing results back into a spreadsheet or CRM.
A useful execution environment must preserve state without exposing secrets
Ngiam says ordinary code interpreters run in locked-down sandboxes that cannot access the web, APIs, other AI functions, or external systems. Lutra needs a sandbox that can reach outside systems while protecting credentials and secrets. It also needs to preserve the working state of an agent between conversations. A temporary notebook-style kernel loses variables when it disappears, but leaving a machine running indefinitely costs money. His team is working toward a secured, more stateless runtime that stores memory and execution state while controlling how code is interpreted and resumed.
Long-running jobs need progress, cost controls, and review points
An agent processing 100,000 rows cannot simply run silently. Ngiam wants the runtime to show which actions are happening, how long the work has run, and an estimate of remaining time. It should also estimate AI usage and warn when a loop may consume many credits. Users could start with a small sample, review the output, and then approve a larger run. Ngiam says a single prompt may eventually trigger days or months of work, so the interface must make the scale and consequences visible before the job proceeds.
Cheaper models change how much reasoning an agent can afford
Ngiam identifies context length, model cost, and output quality as major factors in agent design. Larger context windows let systems provide whole documents and detailed debugging traces instead of carefully trimming inputs. Lower costs make repeated model calls practical, which supports iterative reasoning and self-debugging. He describes selecting models for particular jobs, such as using Gemini Flash for data extraction and another model for mapping and reasoning. He expects prompt caching, larger output windows, multimodal inputs, and lower prices to make more complex agent workflows feasible.
Future software may generate its interface around the task
Ngiam thinks current software is designed around fixed controls chosen in advance by developers. An AI system could instead inspect the task and create an interface that explains its work in a form suited to the user. For video editing, an agent might run the underlying commands while generating a temporary visual interface showing how clips are being cut and reordered. He also imagines software that offers controls based on the kind of material being edited. Users would not need to know every technical term because the system could suggest styles and operations, then learn from their choices.
