Does OpenRig give my agents permanent memory?

No. The FAQ describes a topology where agents sit in defined roles grouped into pods with shared context and lifecycle management, and a seat that keeps its address, role and queued work when the agent changes. That is persistence of the seat and its context, not a long-term memory store you can query later.

Can I use it for lead intake and follow-up agents?

Nothing in the repository or docs supports that. OpenRig is described as a network of agents built from Claude Code, Codex and Pi, which are coding agents. For customer workflows you still need a queue and a database you control.

Is three hours realistic?

It is my estimate from reading the docs, not a measured run. Install plus daemon start is small according to the project site. The time goes on writing down your seats, a dry run and a handover test. If your repository access or credentials are messy, add an hour.

Give your AI coding agents a fixed seat: a 3-hour OpenRig setup

OpenRig is for coding agents, not for your lead intake, and that distinction decides whether the three hours are worth spending.

What it is, precisely

The repository describes OpenRig as software for building and running a network of agents from Claude Code, Codex and Pi, with persistent teams, roles, shared context and owned work. The README's framing is that it turns coding agents from separate terminal sessions into a persistent, organised team.

The FAQ is more precise than most write-ups on this. Agents sit in defined roles, grouped into pods with shared context and lifecycle management. A seat keeps its address, role and queued work when the agent in it changes.

That last sentence is the whole product. The seat is durable. The agent in it is disposable.

What it is not

It is not long-term memory, and it is not a business automation platform. The getting-started docs say missing roles are reported rather than quietly filled with another conversation, which tells you the topology is configuration you own, not something the tool infers for you.

So if your problem is that a follow-up agent forgets what the intake agent learned about a customer, this is not the fix. If your problem is that four terminal windows of coding agents each start cold every morning, it is worth a look.

Decision table

Your situation	What I would do
Several people run coding agents daily on one codebase	Spend the three hours, on a throwaway repo first
One person, one agent, one window	Skip it, the seat buys you nothing
Agents doing intake, follow-up, reporting	Skip it, wrong tool, fix your queue and your database instead
You need an audit trail of who changed what	Wait, and judge it on the release notes, not on this post

The three-hour setup

These are instructions read off the docs. I have not run OpenRig in production, so every minute figure below is my estimate, not a measurement.

Read the quickstart and install, about 20 minutes. The project site says you install with a shell script and then start the daemon with a single command.
Write your seats down before you create any, about 40 minutes. One line per seat: the role, the repository it owns, what it is never allowed to touch.
Create the pod and fill the seats, about 30 minutes. Expect the docs to report a missing role rather than fill it, so work through the list until the report is clean.
Dry run on a throwaway branch, about 30 minutes. Give one seat a small, boring task and watch what it writes.
Handover test, about 25 minutes. Stop the agent in a seat, put a different one in, and check the queued work is still addressed to that seat, which is the behaviour the FAQ describes.
Pin the version and write the rollback note, about 35 minutes. Latest release is labelled v0.6.9, so record the version and the two commands that undo the install.

That is three hours. Step two is the one people skip and the one that decides whether the rig is useful.

The arithmetic on your own inputs

Use your own numbers, not mine. If two of your developers each re-brief an agent four times a day and each briefing costs five minutes, that is forty minutes a day of typing context back in. Over a twenty-day month that is a bit over thirteen hours. A rig that removes half of it pays back the three-hour setup in the first week, and nothing if your team re-briefs twice a week instead.

Limitations

Early software. A release labelled v0.6.9 means the interface can change under you.
I have not tested it. Everything above comes from the repository, the site and the docs.
Coding agents only. Nothing in the sources I read supports using it for customer-facing workflows.
Seats are not memory. Shared context inside a pod is not the same as a durable record of a customer, and my guess is people will conflate the two for the next few months.
No independent numbers. There is no benchmark here on setup time or on tokens saved, so do not plan around one.

My take

The idea is right. The thing worth copying is not the tool, it is the discipline of writing down the seats, because the role sheet is useful even if you never install anything. I would run it on a side repository for a week before letting it near the work that pays. More build notes are on the blog.