Introducing TulipFarm, one workspace for your business operations
By Dhruv JainOn this page
TulipFarm is a hosted workspace for business operations. You describe the work in chat, and agents create and use the records, knowledge and workflows needed to do it. Everything they build stays in one place, so the next person picks up the work instead of rebuilding it.
We built it for small business owners, operators and the teams inside their companies: marketing, sales, support, engineering and the back office. This post covers what TulipFarm does, how a request turns into working parts, where we draw the safety lines, and what is not finished yet.
The problem is the gaps between apps
Most businesses run recurring work across many separate apps: spreadsheets, docs, task boards, email and chat. Each app does its job. The trouble lives between them. A customer's history is in one spreadsheet, the follow-up policy is in a doc, the decision to make an exception is in a chat thread, and the person who knew all three just went on leave.
Adding an AI assistant to each app does not close those gaps. Each assistant sees one slice. We wanted one workspace where the records, the context and the decisions sit next to the agents that use them.
What lives in a workspace
A TulipFarm workspace holds a small set of parts that fit together. Each one has a clear job.
| Part | What it holds |
|---|---|
| Tables and rows | Definitions of business objects, such as customers or invoices, and the rows that hold each one's data |
| Agents | Named assistants with instructions, selected tools and selected skills |
| Skills | Reusable procedures an agent loads when it needs them |
| Workflows | Repeatable work and the trigger that starts it, including steps that wait for a person |
| Knowledge and files | Notes, documents and uploads that agents can cite |
| Projects | Shared chats, instructions and files for a group of people |
| Integrations | Connections to Google Workspace, Slack, GitHub, and Atlassian and Trello |
Chat sits on top of all of this. It is where you ask for an outcome, watch progress, answer an agent's questions, approve changes and inspect the result.
How a request turns into working parts
Take a request like "track our customers and follow up when we have not heard from them." In TulipFarm that one sentence touches most of the workspace:
- Define customer and follow-up tables with their fields and relationships.
- Store the actual customers and follow-ups as rows.
- Give an agent instructions, the relevant skills and limited access.
- Connect the external account the work needs, such as an email account.
- Use knowledge, like a contact policy or approved wording, to guide the agent.
- Run the work on request, on a schedule, or when an event happens.
- Ask a person for approval where it matters, and record what actually happened.
This is the path we design toward, and we want to be precise about it: several of these steps work today on their own, but we have not yet shown the complete journey working end to end in Cloud. We will write about it when we have.
Definitions and business data live separate lives
To see why TulipFarm keeps work repeatable, you first need one distinction. A customer definition describes what valid customer data looks like. A customer row holds one customer's actual information. Changing an agent's instructions changes a definition. Sending an email is an action with its own outcome.
TulipFarm stores authored definitions, the tables, agents, skills and automations that exist, in a version-controlled history we call the Soul. Rows, messages, run history, knowledge and files have their own storage. When you change how the business works, you change the Soul. When the business does its work, the rows change.
The same care applies to state. Saving a definition, activating it, running it and completing the work are four different outcomes, and TulipFarm keeps them separate. An agent you saved does not run until someone activates it.
Agents work inside the limits you set
An agent in TulipFarm gets explicit tools and limited authority. Permission checks, approvals and execution records decide what it can do. An instruction in a prompt is not a permission check, so we never treat one as a substitute for the other.
A few rules follow from that:
- Skills grant no access. A skill adds a procedure, not a tool or a permission.
- Record changes wait for the task owner. An agent proposes an exact set of changes with before and after values. If the records change before you approve, you review a fresh proposal.
- Admin status is not data access. A workspace admin manages members, settings and tables, but reaches private chats, projects and agents only through the same grants as anyone else.
- Access can only narrow. An agent's permission limit can restrict what its teams grant. It can never add access.
We cover how agents, skills and tasks fit together in more detail in a separate guide on this blog.
What is not there yet
We would rather you hear the gaps from us:
- Setup recipes, which apply a reviewed set of tables, rows, workflows, agents and skills in one approval, are specified but not built.
- Inbox is a placeholder.
- Search in the app navigates pages and quick actions. It does not search chat messages, agents, workflows or files.
- Agent tasks cannot call Google Workspace or read GitHub issues yet.
We are not building a replacement for every specialist tool you use, and we are not promising an autonomous company. TulipFarm keeps your operations in one place and puts agents to work on them, with you deciding where they stop for your OK.
Try it
You can explore TulipFarm in your browser at tulipfarm.ai/playground before signing up. Explore keeps everything in your browser, and its integrations and workflows do not run real actions, so it is safe to poke at.
When you are ready, sign up for Cloud. Your first signup includes $50 in free credits to plant your first agents. For more credits, get in touch. Student, NGO and startup teams can apply for support by emailing [email protected].