Project history could be saved. Current understanding still had to be maintained.
Working with AI let me move through projects much faster, but it also created more context than I could reliably carry from one chat to the next. I started exploring whether AI could help maintain that current understanding instead of forcing me to reconstruct it each time.
I compared raw history, stronger reconstruction instructions, and a maintained summary. The maintained approach worked best, but an early failure exposed a deeper problem: preserving the conclusion wasn't enough if the source evidence and decisions that made it trustworthy were lost. That shifted the project from reconstructing context to deciding which parts of maintaining it should belong to AI at all.
The problem was no longer just preserving context.
I realized I didn't want important project truth to depend on what an AI remembered or reconstructed at all.Looking at how AI teams handle context, I found the same underlying problem: finding information is one thing; knowing what should still be treated as current is another.
I needed an external record that kept new evidence separate from what a person had actually accepted as the project's current understanding.
I kept going because I wanted to understand a harder question: where should AI help, where should software enforce the rules, and where should people stay in control?
State maintains a current, trustworthy, human-approved understanding of a project as new information arrives.
The core loop is simple:
New Evidence is interpreted into a Review, and a person decides whether Current State should change. A Review can instead leave Current State unchanged or keep an unresolved Question visible. The rest of State supports that same boundary between what came in and what the project has actually accepted.
Meeting notes and other approved sources are preserved as evidence.
What the project currently treats as true. New evidence only becomes Current State after a person authorizes it.
AI proposes what new evidence means. A person decides whether Current State should change.
Reviews, blockers, and open questions stay visible without being mistaken for facts.
Accepted changes preserve what changed and why.
Answers keep accepted facts separate from pending or unresolved information.
State keeps the evidence, AI interpretation, human decision, and resulting change traceable.
Only approved Slack channels are evaluated automatically into Evidence. Other Evidence is added manually.
AI can interpret what changed. It cannot decide what becomes true.
I expected a product like this to lean on the model for more of the work. Instead, AI was useful for interpreting messy evidence while software was better at enforcing rules. Consequential changes still needed a person's sign-off. Knowing where not to use AI became as important as deciding where to use it.
AI can propose changes to Current State, but only a person can authorize them. Future agents could investigate questions or gather evidence, but the maintained truth would stay behind that same boundary.
Early on, the model turned an unresolved automation target into a confident 0%. It fit the schema perfectly but stated a decision the project had never made. That failure made the distinction between technically valid output and trustworthy product behavior concrete.
State first filters for consequential changes, then separates only the decisions that need independent judgment. Otherwise human review can become more work without adding more control.
State is most useful when a team needs more than a plausible summary.
It fits best when project context changes often and earlier decisions may need to be revised without losing track of what currently counts as true. State also changed how I think about AI products. I started out assuming I'd use AI in more of the system and came away believing that using it well often means restraint. AI can interpret change, but people decide what becomes true.