Rill
← All articles

Building Rill

What using Basecamp with an agent made us think about Rill

By the Rill teamPublished

Seeing Basecamp 5’s release, including its support for working with agents, made us create an account and try it for organizing work on Rill. We connected Codex and gave it a real job: help us organize the backlog we had been collecting.

As we used Basecamp together, we started thinking about the experience of having a human and an agent working in the same product. Some of the ideas we now want to explore in Rill came directly from using it.

Building Rill produces a lot of ideas.

Some come from using the product. A recording fails halfway through, a player control feels awkward, or someone needs a better way to share a browser run. Others come from customer conversations, competitor research, or thinking about what to build next.

Those ideas accumulate quickly: scheduled recordings, better onboarding, integrations, native apps, launch emails, pricing changes, tutorials, and dozens of small improvements.

We had been capturing them in a long checklist. It preserved the thoughts, but finding the next useful piece of work meant reading through repeated reminders, old timestamps, unfinished ideas, and completed tasks.

We started by bringing our completed work into Basecamp: 206 to-dos and six subtasks, with the original notes, dates, links, and nested tasks preserved.

Then we organized the unfinished work.

That needed more judgment than copying each line into a new task. “Create a Discord community” appeared several times. Onboarding ideas were scattered across different dates. Payment-failure emails showed up in more than one place. Some broad headings contained several unrelated tasks.

Codex consolidated repeated work, separated distinct ideas, and kept the useful context. The result was 229 organized to-dos across twelve topical lists, covering recording and playback, reliability, integrations, native apps, onboarding, billing, design, content, growth, research, and admin.

When we’re working on recording reliability, we can now find encoding failures, upload performance, and error handling together. When we’re preparing a launch, the content and outreach work has somewhere clear to live.

Research also gets its own place. A framework to investigate or a competitor to benchmark can stay visible without becoming an immediate implementation commitment.

The descriptions matter as much as the structure.

“Fix remote encoding failures” becomes more useful when its description explains that the first segment uploaded successfully, remote encoding then failed, and the continuation used local encoding.

We kept that context, along with design references, article ideas, and integration notes. Where several reminders described the same work, their notes were combined under one task. Matching tasks already open in Basecamp were reused.

We created a separate Basecamp profile specifically for the agent, giving its actions a distinct identity in the project. Tasks still had explicit owners, and team members’ existing work was organized into appropriate lists.

While this was happening, we were also using Basecamp ourselves.

We completed tasks as the agent was organizing them. It noticed that the project had changed, asked whether to preserve a completed status, and continued without undoing our work.

That made us pause and think: how should this feel when humans and agents are regularly working together?

We could see the agent’s changes, make our own changes, and keep going. But it also raised questions we want to spend more time with. When should an agent ask? When should it continue? How can a product make it easy to understand what the agent is doing without needing to watch every action?

By the end, we had a backlog the team could navigate, with the original thinking still attached to the work. We also had some concrete ideas to take back into Rill.

One is the experience of adding an agent.

In Rill, that action is currently tucked away in Settings. After using Basecamp this way, we’re thinking about bringing it forward into a more prominent workspace surface.

An “Add agent” action could be visible where people begin working with recordings. The agent could have a name, a clear description of what it can access, and a visible history of its activity. We want to explore what it would feel like for an agent to belong in the product as a recognizable participant.

Rill gives people a way to record browser workflows, record an agent’s work, or ask Rill to run a flow. The result is a recording they can review and share. Agent and cloud browser recordings can also include console output, network activity, and an interaction timeline; screen recordings do not automatically capture those diagnostics.

That gives us a specific place to think about collaboration.

Someone watches a recording and notices that checkout failed. They point to the moment that needs attention and ask an agent to investigate. The agent uses the recording and its evidence, works on a fix, and returns with another recording showing what it tested. The person can then review that result and continue the conversation.

We want to make those handoffs easier to follow: which recording the agent used, what it was asked to investigate, what it did, and what still needs someone’s judgment.

Using Basecamp with an agent gave us more than an organized backlog. It gave us a practical way to think about Rill’s next steps: making agents easier to add, their work easier to see, and the conversation between a person, an agent, and a recording easier to continue.