Integrations
Connectors are not the product — they are how the evidence arrives. What matters is that six of them collapse into one thing that has an owner, a reason, a cost and a definition of done.
The model
Requests and commitments nobody filed
Assigned work and decisions it waits on
Reviews standing between a branch and a release
External asks and the dates attached to them
What a meeting needs decided beforehand
Comments and approvals left open
One responsibility
Confirm the retry limit before Friday’s freeze
Six systems. One object — with an owner, a reason, a cost and a definition of done that none of the six could hold on its own.
Connectors gather the evidence. What is hard, and what this is for, is everything that happens to it afterwards.
Illustrative dataBy what it gives you
The largest source of dropped work, because almost none of it is ever written down as a task.
Trackers know what was recorded. They do not know that an issue has been sitting on a decision only you can make.
A review nobody picked up is the most measurable blocker in software: one person waiting, a release window closing.
Most meetings need something decided beforehand. That preparation is a responsibility with a hard date attached.
Commitments to customers and partners have consequences that internal ones do not, and they arrive in prose.
Approval is where work stops most quietly — the document is finished and simply waiting for someone.
Not a hub
Plenty of products connect to all of these. Search tools index them, automation tools move data between them, and universal inboxes stack their notifications in one list.
Open Threads is not doing that. The connectors gather evidence; what the product is actually for is everything that happens next — working out that something needs a person, which person, what it is costing while it waits, and what would count as finished.
Adjacent, not identical. A team can own every product above this line and still not be able to answer the last question.
Design partners
We are partnering with a small number of teams whose important work crosses several systems — to shape which integrations come first, and what it takes to make this dependable in real work.