AI and Intent in Software
We do not usually talk about software in terms of intent, but it explains a great deal about how systems behave once they are put into the world.
Software is how we tell machines what we want to be true as reality unfolds: what matters, what takes precedence, and what tradeoffs are acceptable as conditions change. A spreadsheet carries intent about how money should be reconciled. A CRM carries intent about how relationships should be managed. A scheduling system carries intent about how work should be sequenced, interrupted, and resumed.
The machine does not decide. It executes what was implied. That has always been true. What has changed is whether that intent can survive change.
For most of the history of software, translating intent into plans was costly. It required rigid logic and early commitment. Because that translation was expensive, intent was pushed down into code, workflows, and configuration and then left there. Once translated, intent hardened.
When reality changed, the software often did not. People felt the gap as friction. Workarounds appeared. Offline spreadsheets multiplied. Overrides became routine. Everyone sensed misalignment, but the cause was difficult to name: the intent layer was simply inaccessible. This was not a failure of tools, but a limitation of what software could reasonably hold.
The Construction Gap
That limitation is easiest to see in construction planning. For decades, planning and scheduling were treated as separate disciplines.
Planning captured meaning: why the work existed and what promises had been made.
Scheduling dealt with feasibility: labor, weather, and time.
Because software could not reconcile these axes, experienced coordinators carried both models in their heads. They translated between them through judgment calls and rework. That burden lived in people, never in the system.
A construction schedule looks objective, but it reflects decisions that live outside the bars on the chart. When client commitments conflict, precedence must be determined. When a milestone is at risk, someone decides what work can slip. These are not tasks; they are judgments about obligation and risk. Nearly every task depends on them, yet they rarely appear in the software. That is why plans can fail even when no dates move.
From Motion to Meaning
Over time, we moved from static spreadsheets to visual, drag-and-drop scheduling tools. These made it easier to move work around, but they did not make it easier to replan.
Every meaningful change still required the same hidden work: reconstructing intent from emails, conversations, and memory. The system could reflect motion, but it could not reason about meaning.
This is where AI begins to matter. AI does not merge planning and scheduling; it exposes how much effort we spend reconstructing intent whenever conditions change.
Weather exposes this difference immediately. Traditional systems treat weather as a variable that pushes dates. In reality, weather challenges assumptions such as:
Exterior work can proceed safely.
Temporary protection is sufficient.
Lift operations are acceptable.
Access routes will remain usable.
Commitments made under normal conditions still hold.
An intent-aware system does not immediately move the bars when a storm appears. It first surfaces which assumptions are under pressure. This allows teams to decide whether to protect, resequence, or renegotiate before anything is executed.
The Architecture of Intent
This implies a shift in system architecture. We are moving toward an intent layer that sits between human judgment and downstream computation.
Instead of binding meaning directly into the schedule, the intent layer tracks which phases rely on the same promise and which activities are valid only if certain conditions remain true. This turns the schedule into a compiled artifact: a projection of intent at a moment in time.
When reality shifts, the system does not quietly overwrite the plan. Instead, it marks the affected projections as stale. It identifies exactly where the “why” no longer matches the “when,” inviting human judgment to revalidate intent before the machine regenerates the output.
Where Intent Comes From
The most efficient way to capture intent is not to ask people to rewrite what they already know. It is to ingest the artifacts the job already produces: emails, proposals, estimates, drawings, and meeting notes.
Structured and unstructured information is fed into the intent ingestion machinery. Over time, this produces a working set of intents. Some are reusable (e.g., “Public egress must remain open”), while others are specific to a single coordination promise. Intent simply appears where it applies.
How Intent Appears in the Interface
The primary interface mirrors how a job is actually experienced. Work is arranged left to right in a board made up of phases rather than micro-tasks.
Each column represents a coordination zone where certain conditions must remain true for work to proceed. Intent appears with the work it governs:
Job-wide conditions sit above the board.
Phase-level intent lives inside the columns.
Constraints are visible at the exact point they matter.
Seeing Consequence Before Execution
Imagine a building manager notifies the team that a primary access route will be unavailable for several days. Nothing moves yet.
Instead, the system reveals that multiple phases rely on that same access condition. Those phases surface together, not because of sequence, but because they share a promise that is now in question. The team can see, spatially and immediately, the reach of that disruption.
That moment answers the real planning question: Not what should we move, but which promise are we about to reconsider, and how far does it reach?
Closing Thought
If intent can be captured and managed, most of what follows becomes mechanical. Sequencing, scheduling, and regeneration stop being acts of continual reinterpretation and become acts of execution. The hard part is not calculating outcomes. It is knowing what must remain true as conditions change.