Lindy at Work: Putting Agents on Rails

A briefing before the meeting

Thirty minutes before a meeting, Andrew Wilkinson’s agent texts him a briefing: a participant biography drawn from LinkedIn, plus context from recent emails. Charlie opens the Latent Space conversation with this example of an agent gathering information across applications and delivering it when needed.

Florent Crivello describes [Lindy](https://www.lindy.ai/) as a no-code platform for automating business workflows. Users configure agents through an interface rather than assembling the underlying machinery themselves. His positioning analogy: Lindy is to LangChain what Airtable is to MySQL.

Getting there required a correction. Crivello says the first version was essentially a giant prompt with tools attached, built with too much confidence in what models could reliably do. Lindy 2.0 followed roughly six months of rebuilding and began reaching users about two months before the interview. Its internal name captured the change: Lindy on Rails, where users specify steps and choose how much discretion the agent receives.

Make required work part of the workflow

Crivello’s clearest example is a Zendesk support agent. Originally, a prompt instructed it to consult a knowledge base before answering a ticket. That left a mandatory requirement dependent on the model choosing the right tool. The redesign encodes the sequence directly: 1. Receive a Zendesk ticket. 2. Consult the knowledge base. 3. Pass the resulting context to the agent to answer. Retrieval becomes a required step. The model no longer decides whether to perform it—a change Crivello describes as a substantial rewrite.

Swyx generalizes the pattern: confine model-driven behavior to the smallest part of the system that needs it, and implement surrounding conditions with conventional software. Crivello agrees. Explicit steps also help users express intent: selecting actions is easier than writing an entire operational policy into an empty text field. He reports better reliability and easier setup after the redesign, without a quantified benchmark.

Watching users configure agents changed Crivello’s opinion of text interfaces. Engineers may imagine the structures and actions behind a prompt; other users struggle to turn a goal into actionable instructions. His informal estimate from user calls is that a majority of entered prompts were unclear even to him. A graphical interface helps specify intent as well as constrain execution.

Permissions introduce a different tradeoff: narrow access can mean repeated authorization. Alessio reports that connecting Slack requested access to all channels. Crivello describes Lindy’s policy as requesting the least access needed at each moment: an email drafter asks separately to read messages and write drafts, and some Google setups required five or six authorization steps. He is unsure whether Slack supports the requested channel-level restriction.

Some users instead provision a separate Google Workspace account for an agent. They CC the scheduling assistant into an email thread, where it negotiates availability; some add reply delays to make it appear human. Separate accounts are described as a workable but awkward substitute for finer access controls.

Extract fields, then keep the conversation open

The demonstration starts with rental reservations. A workflow filters incoming emails for booking confirmations and appends their details to a spreadsheet. Each output field is configured through a prompt requesting the start date, amount, or traveler count. This replaces the work of maintaining an HTML email parser as formats change, though no comparative reliability measurement is offered.

The append-row node is a mini-agent with the preceding task context. Its extraction uses one structured-output call: the model returns the requested fields for the operation. Users can select a model separately for each node; the examples include Claude and GPT-4 Turbo. Lindy uses structured outputs broadly, with plain-text exceptions such as AI-agent and send-message steps.

A meeting recorder extends this into a longer interaction. It records a meeting, sends a summary and personalized coaching, then distributes notes in Slack. Coaching prompts can ask whether the user was too confrontational, not confrontational enough, or should have explored an issue further.

The distinctive behavior is resuming an earlier interaction after the workflow has moved on. Replying to a coaching email restores the relevant task and meeting context. In one reported exchange, Lindy criticized a sales explanation as too technical. Asked why, it cited the terms “deterministic,” “context window,” and “agent state.” The email remains an entry point into the task after later actions have run.

Meeting notes in Slack likewise support follow-up questions, including about meetings the questioner did not attend. The demonstrator reports sometimes replacing roughly an hour of attendance with five minutes of subsequent chat—a personal usage account that illustrates the value of retaining context behind a summary.

Choose what persists—and what belongs in one agent

Lindy’s memory module retains information across executions, including scheduling details and user corrections. The agent decides what to remember, and a duplicate appears during the demonstration. The demonstrator manually prunes memories because excessive accumulation can confuse agents, a habit dating to GPT-3.5. They suspect Claude 3.5 Sonnet may make pruning less necessary, without presenting a comparison.

The discussion separates two retention policies: - Let the agent select memories. Observations and corrections can survive into later tasks, but duplicates and trivial facts create pruning work. - Remember explicit user rules. An inbox-processing Lindy accepts forwarded emails with instructions to archive similar messages or send Slack alerts. Its prompt directs it to save these rules through a provided memory-saving skill.

A fixed sequence still leaves choices inside each step. A personal assistant accepts blood-pressure readings, updates a health log in Google Docs, and sends a response. With no message content configured in the send-message node, it generates unsolicited lifestyle suggestions. Specifying the action did not specify everything the model would say.

Even the agent/workflow hierarchy needs explanation. One participant already using Lindy had assumed a single start-to-end workflow and did not realize that one Lindy could contain several. The demonstrator proposes practical boundaries: - Group routine personal tasks in an everyday assistant. - Separate substantial specialized work, such as summarization or designer recruiting. - Separate agents serving different people, such as customers rather than the owner. Each Lindy has its own task history, and one Lindy can call another.

A shared platform still needs specialized engineering

Two further workflows show how integrations and configuration turn general capabilities into useful routines: - Podcast following: a weekly agent finds the latest Lenny’s Podcast episode on YouTube, transcribes it, and emails a summary. - Pull-request review: an agent reads roughly forty pages of engineering guidelines in Google Docs. When a new category of bug occurs, the team adds guidance asking the reviewer to watch for it.

A simple action can conceal substantial conventional code. The scheduling action for finding available times is described as roughly a thousand lines long. It handles meeting duration, start and end boundaries, eligible weekdays, the number of slots to return, and buffers between meetings. That implementation gives the model a usable scheduling operation.

Lindy’s horizontal-platform thesis is that agents across industries share enough requirements to spread this engineering investment across many use cases. A common platform also lets agents cooperate and reduces the interfaces customers must learn. The demonstrator acknowledges having no crisp rule for choosing a vertical product—one specialized for a particular market—over a horizontal platform serving many markets.

Vertical and horizontal agents can coexist. When an interviewer interprets the thesis as predicting that vertical AI software businesses will mostly fail, the response explicitly rejects that conclusion. The forecast is for widespread specialized agents alongside a few large general platforms, with vertical products emerging earlier because they are easier to build.

Distribution raises a more immediate question: who will configure the workflows? Lindy reports an active Slack community and growing user sharing of agents. A participant recommends building around the broader no-code category. Positioning Lindy as an executive assistant for CEOs might reach different budgets, but the response identifies a practical obstacle: many CEOs will not tinker with the platform. Solo entrepreneurs and small-business owners are presented as more natural users.

Turn unexpected failures into evaluations

Asked for video tutorials that did not yet exist, Lindy’s customer-support agent supplied a Rickroll link. The team says human review caught the exchange and a correction went out before the customer opened the original email. A database query reportedly found another three or four incidents. Tutorials subsequently became available through Lindy Academy.

The team reports stopping the behavior with a system-prompt instruction against Rickrolling, without giving a follow-up period or recurrence rate. Participants speculate that repeated misleading uses of the URL in training material explain the failure. That hypothesis leaves a practical problem: how do you test for behavior nobody anticipated?

Lindy uses conversation histories as evaluation cases. Its internal tooling turns a conversation into an evaluation in one click, effectively creating a unit test. Good conversations record desired behavior; bad examples are edited to show the intended handling. Operational surprises become reusable tests.

Owning that infrastructure has proved less attractive. The team began building in late 2022, when it says suitable tools were unavailable, but now describes its evaluation tool as fragile and expensive to maintain. It advises against building one internally. Braintrust was under consideration, based on conversations rather than hands-on use; no migration had occurred.

The participants differ on who should carry the testing burden: - Evaluate each customer’s agent: one participant argues that constrained workflows and structured outputs reduce the platform’s burden, making individual agents the more important testing target. - Keep evaluation work off the customer: the response describes an ideal where users need not manage evaluations and reliability is judged against human performance. Lindy is claimed to outperform humans for most use cases then served, especially constrained workflows, but no defined human baseline or benchmark accompanies that claim.

Reuse corrections and preserve context prefixes

The Lindy team identifies integrations, core capabilities, and product engineering as its main bottlenecks. It began with context windows—the input available to a model—of roughly 4,000 tokens; its system prompt alone had since exceeded that size. Claude 3.5 Sonnet is identified as the point when model capability stopped feeling like the limit. Prompt caching subsequently reduced costs, though no savings are quantified.

A confirmation toggle already lets users inspect an outgoing email, approve it, reject it, or edit it before delivery. A feature under development would reuse those edits on future tasks: 1. Save the user’s correction. 2. Embed it in a vector database for later retrieval. 3. Retrieve relevant examples for a future task. 4. Insert them into the model’s context. The mechanism adapts future behavior by supplying examples; no model-weight update is described.

An append-only context ledger helps Lindy reuse prompt prefixes through caching. Workflow nodes append information, and subsequent nodes inherit the accumulated context. New material extends the prompt while earlier portions remain stable. The speaker says this arrangement works well with Anthropic’s caching, without establishing an exact cache interval.

A participant describes the same layout principle in a podcast tool: static material first, dynamic inputs last. They rewrote prompts after noticing that variable inputs near the beginning disrupted the stable prefix needed for caching.

Build for better models without ignoring today’s costs

The conversation broadens into a forecast that labor-replacing software will create trillions of dollars of value within a few years. A sales anecdote imagines configuring Lindy in a day or two for work handled by a twelve-person team. This expresses the speaker’s market thesis; it does not establish a completed deployment, equivalent performance, or actual staff reductions.

The architecture preference follows that optimism: rely more on stronger models and less on elaborate arrangements of generators and critics. Lindy evaluates features by asking whether model improvements will solve the problem without more product work. Context-pruning work begun in 2022 to fit 4,000-token windows later became obsolete. The team’s speculative planning assumption of extremely large, cheap context windows directs attention toward the model’s inputs and outputs.

A participant challenges this preference with a secondhand report that Michele from Replit found a multi-agent approach particularly valuable. Coding may have different requirements from Lindy’s tool-oriented workflows. Lindy no longer generates code following its architecture change; users can still prompt it to reason carefully, with small improvements reported for certain uses but no quantified evaluation.

Computer use exposes the limit of waiting for progress. Although it had featured in Lindy’s roadmap discussions, the speaker favors API execution wherever available, arguing that direct programmatic access retains substantial performance and reliability advantages over computer use. Expected improvements do not erase current costs: a product can carry avoidable overhead for years.

Asked whether tools inside ChatGPT could make OpenAI a more direct competitor, a Lindy representative emphasizes distinct jobs to be done and says OpenAI’s plugin architecture permits reuse. Lindy’s business workflows include lead generation, outreach, and joining Zoom meetings to take notes. The response characterizes ChatGPT at the time as primarily a consumer application, while acknowledging its enterprise offering.

Manage agents by constraints, and teams by more than visibility

Lindy’s horizontal ambitions also shape its human organization. It hired general managers to own vertical markets, including go-to-market work and template customization, drawing inspiration from Uber’s geographic GM structure. Responsibilities were still evolving: the CEO’s daily work included product, recruiting, and management alongside vision, culture, and fundraising.

A [Factorio](https://www.factorio.com/)-like future business would put thousands of agents inside a Slack-like interface. The operator’s job would be to understand the organization and find the interventions with the greatest impact. An illustrative comparison replaces a two-month designer search with rapidly starting fifty AI designers. Another participant stresses the potential to duplicate a known effective agent, beyond merely accelerating recruitment. These are future scenarios.

The author of the discussed Factorio tweet resists making it a sweeping philosophy. The narrower recommendation is to address the current constraint with a loose direction in mind, while preserving planning and organization. A participant connects this to finding a small, fully inspectable Lindy template more useful than a large automation they could not understand.

A Cursor anecdote reinforces the appeal of incremental work. One participant gave o1 a large upfront specification, received a tangled codebase, and spent roughly two hours trying to recover. They discarded it, started small, changed models, and built working software through successive additions. Because both the model and strategy changed, the account cannot isolate which produced the improvement.

That leads to legibility: how understandable a system is from above. Drawing on a discussion of Seeing Like a State, a speaker argues that top-down visibility can come at the expense of bottom-up performance. Lindy’s tool choice provides a small example. The founder valued Notion’s unified view of roadmaps, tasks, and linked postmortems, but accepted the team’s request to adopt Linear. The choice reduced that visibility while letting the team select its own tools.

Shared mental models and the case for proximity

The remote-work discussion begins with a reversal. The speaker describing an earlier business, [Teamflow](https://www.teamflowhq.com/), had built a virtual office and strongly advocated remote work. Global hiring, lower rent, and avoiding commutes initially looked compelling. After three years building software to improve remote collaboration, they concluded that working together remained too difficult for their team.

The proposed mechanism is alignment on the product’s invisible design. Much of software lies beneath its visible interface, and the speaker believes quality depends on teammates sharing a mental model of that underlying structure. A participant challenges the office-versus-remote framing: companies spanning buildings or cities are already partly remote. The response distinguishes a distributed company from individual teams that can still work together in one location.

The speaker distinguishes two kinds of work: - Magnitude: executing a known task faster or more cheaply. Standardized support work can favor remote or offshore teams. - Direction: deciding what to build. The speaker defines this as creative work and argues that being together improves it. Linear is offered as a remote company building within a known product category, contrasted with Lindy’s recurring struggle to define a new kind of product. These are judgments from experience, not measurements establishing that work arrangements caused company outcomes.

Predictable automation does not exclude creative uses. A participant’s suggestion that people probably do not use Lindy for brainstorming is immediately corrected by someone who reports doing so frequently. The group also proposes creative applications where hallucinations could be useful, without developing an implementation or evaluation.

The proximity argument expands to San Francisco. One participant strongly maintains that ambitious AI founders should be there, while accepting that other life priorities can justify living elsewhere. Personal accounts of greater startup risk appetite in the United States and an unsuccessful effort to shift into Miami’s technology scene underpin the participants’ belief in geographic network effects.

Europe produces disagreement. One speaker blames regulation and taxation alongside entrenched geographic networks. Another cites UK AI institutions, Mistral, and Hugging Face as successes; the response argues that individual companies do not establish broader economic competitiveness. The exchange offers competing interpretations, without measurements resolving them.

Dissent, AI risk, and designing the whole journey

The political discussion turns to self-censorship as a source of apparent consensus. A speaker argues that people conceal beliefs because everyone else appears to agree, and describes a deliberate practice: identify an opinion that feels socially unsayable, examine whether they believe it, and express it if they do. Serious concern about AI safety becomes their example of dissent within their own peer group, including losing support from valued accounts.

The speaker connects this practice to French education and discussions of resistance during World War II, explicitly distinguishing present disagreements from that historical situation. Their argument is that defending a belief when the personal stakes are low prepares someone to do so when it matters. A subsequent misunderstanding sharpens the distinction: the relatively low stakes concern speaking up about social issues; the respondent says AI safety’s stakes could not be higher.

The interviewers ask how that concern fits with building increasingly capable AI products, and whether participation makes development safer than withdrawal. The respondent gives a subjective intuition of roughly a ten-percent chance of catastrophe and a ninety-percent chance of a disease-free, post-scarcity future, while saying they cannot meaningfully quantify those probabilities. They favor pursuing the upside while remaining concerned about the downside, locating their acute concern at the model layer and acknowledging that viewing Lindy’s application layer as less dangerous could be self-serving.

The closing hiring exchange mentions design leads and engineering roles. A lighter naming detail follows: the respondent says the team includes a person named Lindy and that the company was named partly after her.

Design supplies the final product argument. An interviewer predicts that AI companies will differentiate through making AI fit into people’s lives, beyond attractive styling, functionality, or benchmarks. The respondent extends that responsibility across the entire chronological user journey, beginning with awareness and brand. Designing those successive layers starts with agreement on the product’s underlying purpose.