Turning project conversations into coordinated work

Running client projects, we kept meeting the same gap across our work: decisions made in calls and Slack threads reached the tracker late, or not at all.

Someone had to translate each decision into tickets, owners and dates. Then the project had to be run: the tracker checked and brought up to date for every standup, one-on-one and stakeholder update. We set out to build the teammate we wanted for both: one that drafts the plan, reads and updates the project in the tools a team already uses, and leaves the decisions with the people running it.

A plan written by AI is only useful if the people on the project can read it, change it and know what will happen when it is sent.

So we designed the plan as a document that opens beside the conversation, not a reply inside it. The person planning edits it directly or asks Sands for changes, and sends it to Jira, Linear or Asana when it is right. Nothing reaches the tracker before then.

Once the work is in the tracker, the same workspace reads it back: what is overdue, what is blocked, how the hours add up, answered from the tools themselves rather than from memory.

Most project questions are asked in Slack, so Sands needed to work there without asking anyone to change how they talk.

So we brought it into threads as a teammate you mention. Ask what was decided and it answers in the thread; ask it to file the tickets and it makes the change, with the asker's own connections and approval mode.

The design problem: let an agent change real project data, and keep what it does understandable and controllable.

Our answer was to separate proposing from doing. The model proposes a change; Sands checks that it was asked for, that it targets the right item, and that the person's approval mode allows it, then runs it under an ID that keeps it from running twice. Each step is recorded as it happens, so what a user watches live is what they can reopen later.

Evaluations score whether a request lands on the right action, including phrasings held out from tuning.

Sands takes something unformed, a conversation, and finds the shape inside it.

We built the identity on that idea. The mark is five grains set in a ring: loose material that has found its order. In motion the grains turn once and settle back into the mark. The voice is plain and direct, like a good project lead.

Sands is easier to understand by watching it work than by reading about it.

So sands.so leads with the product at work, in the order a project runs: a plan written from a brief, the plan changed when a date moves, then the work sent to Jira. A visitor follows one job from start to finish before reading a feature list.

Sands is in private beta. It connects planning and project updates with Jira, Linear, Asana and Slack, and works as an AI agent inside Slack too.

Next, teams plan, run and execute projects together in Sands, with more connectors and capabilities.