Fluid systems of action
A spreadsheet lets a team invent its own way of working. A fluid system of action could extend that freedom to the steps agents perform, with less setup when the company changes its routine.
Table of contents
Behind a company's software is an idea of how that company works. What counts as an order? How does it relate to a supplier? What has been agreed, and what needs to happen before work can move on?
Packaged applications answer many of those questions in advance. Spreadsheets let a team work out its own answers, often while doing the job. That freedom explains something important about why workbooks survive alongside much more sophisticated software.
AI opens another possibility: a fluid system of action. A company could shape its own shared model of the work, have agents maintain it and carry out assignments, and revise both the model and the procedures through use.
What interests us is how much more company-specific work could become practical to automate. The difficulty is getting there without asking every company to design, explain, and maintain the whole system itself.
Business software starts with a model
An ERP system, short for enterprise resource planning, gives people a usable digital model of business operations. Other applications do this for narrower jobs. The purpose is to coordinate work and understand performance: which orders are late, what's holding them up, and who needs to act.
Imagine a clothing brand. An order belongs to a customer, is assigned to a factory, and requires particular materials. Several orders may depend on the same supply of lining. These objects, their fields, and their relationships make up a data model. The entries in it describe the current situation.
The process has a shape too. A production order might move from draft to confirmed, then into production. A state machine describes those stages and the allowed moves between them, with rules about what must be true and who can move the order forward.
Together, the data model and these rules describe the work well enough for people and software to coordinate it.
Packaged software supplies a model built around its view of a domain. That saves a company from designing everything itself. The model usually stays relatively stable while orders, quantities, and statuses change inside it.
Changing an order's date is different from introducing a new approval stage or changing what an order can contain. Those changes are possible too: NetSuite's graphical workflows, for example, support custom records and steps without writing code. But someone still has to define, configure, and check the new arrangement.
The model people build for themselves
Where the packaged model doesn't fit, a team may describe the missing work in files. Our clothing brand might keep orders, factory contacts, materials, and delivery plans in linked worksheets, with formulas calculating the time left before a launch. A document explains how the coordinator handles exceptions.
This is a company-built model too. A column says that something matters. A formula expresses a relationship. A tab gives a new kind of work somewhere to live. The team can add these while it is still discovering what the process should be.
When everyone relies on that workbook as the agreed record of delivery commitments, it serves as a system of record for that work. We can think of it as a fluid system of record: the people using it can reshape what it represents.
In their CHI study of spreadsheet use, George Chalhoub and Advait Sarkar found that the freedom to arrange information in a grid had value that more structured tables didn't fully replace. Familiarity and cost matter, but so does being able to model while working.
The freedom comes with a burden. Definitions drift, files get duplicated, and important rules stay in someone's head. People gather updates, interpret replies, decide what counts, and keep the workbook useful. The flexible record depends on substantial human work around it.
Why not build a tailored app?
Another route is to build the software yourself. Tools such as Lovable Cloud can generate an application with a managed backend, including its database, storage, authentication, and hosting. That substantially reduces the effort of turning an idea into working software.
The remaining job is deciding what software to ask for. Does a material belong to one order or several? Does a confirmed date mean the factory proposed it or the company accepted it? What happens to open work when a rule changes?
An app builder can help implement and revise those answers. The team still needs to discover them, validate the behavior, and maintain the fit. Asking an operator to do all that alone can turn a do-it-yourself tool into another demanding job.
A dedicated app may suit a process that needs specialized screens or carefully guided interactions. A familiar workbook may suit work that is tabular, calculation-heavy, or still taking shape. Not every tracking table needs its own application. The choice should follow how people work and how much effort the system will take to maintain.
Each approach leaves the team with a different kind of modeling work.
| Starting point | How the team shapes it | Work that remains |
|---|---|---|
| Packaged software: an established domain model | Configure or extend records and workflows | Map company routines and maintain customizations |
| Generated app: a tailored app with a managed backend | Generate and revise structure and behavior | Define meanings, check behavior, and maintain fit |
| Workbook: grids, formulas, tabs, and documents | Reshape the model while working | Keep definitions, records, and procedures aligned |
Context doesn't replace the working model
Connecting an agent to company information addresses another part of the problem. A context layer selects what the agent needs for its current task: instructions, documents, conversation history, and results from tools or live queries. Anthropic's context engineering guide describes this broader responsibility.
That context can include an authoritative fact. An agent could query the current order status directly. But finding a factory's email suggesting a substitute material doesn't establish that the company approved it, change the agreed order, or tell everyone what to do next.
The data model gives that request a place and links it to the affected orders. The recorded state distinguishes a proposal from an accepted decision. The state machine defines what can move forward after approval and what must wait. Relevant information helps the agent work within that system.
These are distinct responsibilities that products can combine. Glean's actions, for example, include live reads, database queries, and record updates. Retrieval and execution already coexist; the distinction isn't a division between vendors that search and vendors that act.
The important thing is that people and successive agent runs return to an agreed, maintained picture of the work. They shouldn't have to reconstruct which decisions count from search results or a private chat each time. Some facts can remain in existing applications, provided the system knows where the accepted record lives.
For a substitution request, the flow could look like this:
- Relevant context selected The agent receives the factory message and relevant current shared records.
- Agent checks the request It links the request to its order and asks the product lead for approval.
- Product lead decides They approve or reject the proposed substitution.
- Agent records the decision It updates the shared record and drafts a factory reply reflecting the outcome.
- Shared record guides next task People and agents use the updated record when the next task begins.
Data model: Links the request to its order, proposed material, decision owner, and recorded decision.
Transition rule: Pending becomes approved or rejected only when the product lead decides.
AI changes what can be automated
AI expands the range of inputs and judgments software can help with. An agent can interpret differently worded emails, match a company's shorthand to an order, compare documents, and prepare a question when a reply leaves something unresolved.
Connected to a working model, that ability can support ongoing assignments: collect the missing delivery information, follow up with the factory, and keep the affected orders current. The model gives the agent somewhere to record progress and a way to know what remains unfinished.
AI can also help create and revise the model itself. A team could explain what it needs to track, show examples, and ask for a proposed structure and procedure. Personalization here means the company's own relationships, rules, and ways of working.
Parts of this already exist. Airtable's Omni can create tables and fields and update records. Notion's agents work with documents and databases and support recurring tasks. Configurable models, persistent work, and agent execution are meaningful capabilities today.
One route is to rebuild familiar vertical software, designed for a particular industry, around agents. That can remove substantial work while retaining a predefined model of the domain. The direction that interests us more is helping with the particular processes that remain outside those packages.
Those processes can be useful to automate without justifying a separately built product or agent for every variation. If AI helps establish and maintain the company-specific model as well as execute the work, the economics could change. More teams could get assistance fitted to their operations without every difference becoming a bespoke implementation.
From fluid records to fluid action
Bring these pieces together and the workbook becomes the shared working model, while agents help maintain its current state and carry assignments across documents, applications, and people. The team can also revise the structure and procedures as it works. This is the combination we mean by a fluid system of action.
Suppose our clothing brand introduces a rule that the product lead must approve substitute materials before a factory uses them. Requests previously lived in a notes column. The coordinator could explain the new requirement and work with the agent to add a tab for requests, linked orders, decision owners, and dated decisions.
The procedure changes with it. The agent now brings requests to the product lead, follows up on unanswered ones, and prepares the appropriate reply to the factory after a decision. The factory's proposal stays distinct from the company's approval, and the agent's next steps depend on that distinction.
The team could review and correct both the new tab and the instructions. Changing a delivery date updates data inside the model. Here, the team has revised its data model and state machine together, and the agent uses the new arrangement for subsequent work.
These are two different kinds of change:
| Changing the data | Changing the system |
|---|---|
| The factory reports a later delivery date | The company introduces product-lead approval for substitutes |
| Update the date on affected orders | Add linked requests, decision owners, and dated decisions |
| Continue the existing follow-up procedure | Ask the product lead, record the decision, then prepare the factory reply |
| Same model and rules, new information | Revised model and rules for subsequent work |
Fluidity also matters before a process is settled. The same approach should help a team turn its existing files and habits into a useful system in the first place, refining it through real assignments.
Gil Dibner explores the broader idea in his essay on fluid software. Appfarm develops related thinking about adaptable screens, workflows, and data models. Our interest is in making that adaptability part of the everyday work of establishing and running a company's system.
Flexibility makes shared meaning harder
The first challenge is discovering what the company actually does. There may be no complete process to copy. The workbook, the written procedure, and the coordinator's explanation can disagree, and two colleagues may mean different things by confirmed.
An agent can help expose those differences and ask questions. The company still has to decide which interpretation should govern the work. An exception on one order may reveal a missing rule, or it may be an exception the team never wants to repeat.
The second challenge is preserving meaning while the structure changes. When the brand adds substitute approvals, does the new rule apply to orders already underway? How should an old note be represented in the new tab? Moving its text into a decision field could turn an unresolved request into an apparent approval.
The model and the procedures have to change coherently. A new column achieves little if an agent continues following the old routine. Different people and agents also need to agree on what the revised fields mean and which decisions remain open.
More flexibility doesn't abolish modeling. It changes who does it and how. A readable table with the wrong meaning is still a broken system, even if an agent produced it in seconds.
The system has to survive real work
Even a well-understood process meets untidy inputs. An old factory reply arrives after a new decision. The same message gets forwarded twice. A person corrects an order while an agent is preparing an update based on yesterday's version. A supplier changes its document format.
The system has to recognize stale information, avoid creating duplicate work, and resolve conflicting updates without quietly replacing an accepted decision. When the evidence is uncertain, the uncertainty needs to remain visible. A plausible interpretation of an email is not enough to treat a date as confirmed.
Ongoing execution also means remembering which follow-ups were sent, what answers are still missing, and where a person took over. The shared record must survive across runs and remain understandable to the next colleague. Saved chat history alone doesn't establish that agreement.
All of this costs work. The fair test includes the total time spent on setup, teaching, review, correction, and maintenance, including time spent by the provider or a consultant. If every process change needs a specialist to repair the system, much of the promised advantage disappears.
A new product has to reduce that total burden compared with the company's alternatives, including the effort of adopting it. Faster drafts are useful. Less work to establish and sustain dependable assistance is the larger prize.
Teaching is part of the product
This is the direction we want to explore at Helmstead: shared workbooks that people can shape, with agents maintaining the model and carrying the work forward. Visible changes would let colleagues review, correct, and continue each other's work. Teaching would help turn those interactions into better procedures for future assignments.
That last part needs its own product approach. Giving operators a builder and asking them to specify their whole business pushes the hardest work back onto them. Specialists can do valuable setup, but relying on a fresh bespoke engagement for every company and every change limits which work can justify the cost.
We want software that helps uncover the relevant process, proposes a model people can understand, and turns corrections into agreed changes to future work. That is an onboarding problem that continues after setup. Reliable interpretation and execution still have to be earned on actual assignments.
Starting with one focused use case is compatible with that ambition. It gives us concrete work to understand and test, while building adaptable capabilities that can accommodate differences between companies and changes within one. The next case should show whether what was taught actually helped.
The opportunity is to make a company's own way of working practical to support in software: a model its people understand, agents that act on it, and a way to keep both fitted to the business. That's why fluid systems interest us, and why learning the company belongs at their center.
In the next piece, we'll explore how to teach an agent your company's way of working.
