Work Items in Memex AI are not stories. They don’t have estimation points, acceptance criteria written as “As a user, I want…”, or sprint assignments. Each work item has four properties.
Goal
One sentence describing what it achieves.
Dependencies
Explicit links to other work items AND unresolved decisions that block it.
Acceptance Criteria
Concrete, testable checklist.
Status
Not Started, Blocked (with reason), In Progress, or Complete.
Work Items form a directed acyclic graph (DAG), not a flat backlog. WI-4 depends on WI-1, WI-2, and WI-3. It also depends on D5 and D9 being resolved. The system knows this and can answer the question every team asks constantly: “What can we actually work on right now?”
Before an agent writes code for a work item, it must produce an Execution Plan: a reconciliation of the work item’s requirements against the actual codebase. The plan lists files to modify, dependency flow, and conflicts found between the design and reality. These conflicts always exist. The execution plan is where they surface, before they become bugs.
No coding happens until the execution plan is reviewed. This is the single most effective quality gate for AI agents, because it forces the agent to ground its understanding in the actual code rather than hallucinating an implementation from the specification alone.
A backlog is a list. A list says nothing about readiness: you stare at 80 tickets and guess which one won’t blow up first. A DAG says “these three are unblocked, these six are waiting on a decision, these two are waiting on upstream work that’s still in flight.” That’s the question you actually want answered, every standup, every Monday, every time an agent asks what to do next.
