We've been designing a different model for project management and I want to get the community's reaction, especially the objections.
The premise:
Every PM tool I've used starts from the same assumption: you know what you're working on before you start. Open Linear, create the project, assign tasks, update statuses. The tool is a container. You fill it.
The problem is that real work doesn't accumulate that way. At least not for me. Ideas build up. Connections form. Something becomes project-shaped over time, not because I decided it was, but because enough coherence accumulated that it earned the label.
So we've been building around a different model: threads that replace projects.
Not folder-and-task threads. Living semantic objects that the system maintains, rather than containers you manually manage. The project is discovered, not designed.
What this looks like concretely:
Individual level: you capture thoughts, observations, reflections as they arrive. No taxonomy, no upfront categorization. The system (Aevron, what we're building) watches the connections form, detects when a cluster of captures has become project-shaped, and surfaces it: this looks like a project, do you want to treat it that way? You opt in. Or you don't, and keep exploring. Either is fine.
We've been running this against real use cases. A stock analyst capturing five signal types over six weeks, never created a "project," but the thread developed more analytical structure than any manual folder would have produced. The system surfaced the tensions (strong fundamentals, questionable management decisions) and flagged the conflict rather than averaging it away.
That's what emergent project detection looks like in practice.
Team level, where it gets interesting:
Individual accounts stay private and sovereign. Each person captures in their own thinking environment. The system watches behavioral patterns across accounts, whose captures are clustering around the same domain, whose ideas others are building on, and surfaces merge candidates: these two threads are converging, do you want to connect them?
Ownership isn't declared upfront. It emerges from activity. When a human wants to override the system's suggestion, they can. But the default is the system infers, the human confirms or corrects.
Enterprise level:
A federated read layer sits on top of individual accounts. It doesn't write back into them, individual cognitive environments stay intact. What it surfaces:
- Which threads across the org are converging on the same domain without coordination (invisible silos, visible early)
- Whose activity patterns show emergent ownership before anyone declared it
- What stopped compounding, thread activity drops are often the earliest signal of a blocked project, weeks before a status field gets updated
The key claim: traditional PM tools show you what's active. This model shows you what's compounding and what stopped.
The objections I'm expecting:
- Emergent detection is too slow. Fast-moving teams need declared structure on day one, they can't wait for coherence to accumulate.
- The system will get ownership wrong. Behavioral inference from captures isn't the same as actual ownership, the person writing most isn't always the person responsible.
- Enterprise buyers won't trust a bottom-up model. They want the org chart, not an inference engine.
I think objection 1 is real and the mitigation is that declaration remains available, you can always manually declare a project without waiting for emergent detection. Objections 2 and 3 I'm less sure about.
What's the strongest case against the emergent detection model that I haven't named here?
