<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[Alan Estes]]></title><description><![CDATA[Most AI roadmaps are PowerPoint with a budget. I write about what should come after the deck.]]></description><link>https://www.alanestes.com</link><image><url>https://substackcdn.com/image/fetch/$s_!aZhN!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9895233c-9026-4902-b3e9-21770daea7f1_484x484.png</url><title>Alan Estes</title><link>https://www.alanestes.com</link></image><generator>Substack</generator><lastBuildDate>Wed, 16 Sep 2026 03:20:41 GMT</lastBuildDate><atom:link href="https://www.alanestes.com/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Alan Estes]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[alanestes1@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[alanestes1@substack.com]]></itunes:email><itunes:name><![CDATA[Alan Estes]]></itunes:name></itunes:owner><itunes:author><![CDATA[Alan Estes]]></itunes:author><googleplay:owner><![CDATA[alanestes1@substack.com]]></googleplay:owner><googleplay:email><![CDATA[alanestes1@substack.com]]></googleplay:email><googleplay:author><![CDATA[Alan Estes]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[The Locus of Judgement]]></title><description><![CDATA[An Introduction to Decision Surfaces]]></description><link>https://www.alanestes.com/p/the-locus-of-judgement</link><guid isPermaLink="false">https://www.alanestes.com/p/the-locus-of-judgement</guid><dc:creator><![CDATA[Alan Estes]]></dc:creator><pubDate>Tue, 15 Sep 2026 17:20:33 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!aZhN!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9895233c-9026-4902-b3e9-21770daea7f1_484x484.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Every piece of software you use today is full of decisions someone made once and never revisited. A threshold. A rule. A queue. A routing table.</p><p>But it goes further than the code. Every UI, every report, every dashboard you interact with was designed for the process to stop and wait for a human to make a decision. The screen exists so a person can look, judge, and act. The workflow pauses until someone clicks &#8220;approve,&#8221; reads a chart, picks a priority from a list. This is the architecture of modern work: systems that present decisions but cannot make them.</p><p>These are not features. They are frozen judgment. And for the first time in the history of software, we have the technology to thaw them.</p><div><hr></div><h2><strong>&#8220;But This Is a Deterministic Workflow&#8221;</strong></h2><p>That sentence gets said in every engineering room, every product review, every architecture discussion. It sounds like a statement of fact. It is actually a confession.</p><p>Deterministic execution was never a design goal. It was a constraint we accepted because we could not encode expert judgment at scale. When you could not give a system the ability to reason about context, you did the responsible thing: you froze the decision. You set a threshold. You wrote a rule. You built a queue and staffed it with people. You designed a dashboard so someone with experience could look at the situation and choose.</p><p>That was correct then. It is a limitation now.</p><p>I run workshops with engineering and product teams where we take apart one real workload and hunt for the places where judgment was frozen. I have done this with teams building workforce operations platforms, identity verification systems, financial settlement engines, and multi-tenant SaaS infrastructure. The consistent pattern is not that teams lack AI ambition. It is that they are looking in the wrong place. The biggest Decision Surfaces tend to hide in operations, not in customer-facing features. Once you know how to spot them, the opportunity multiplies.</p><div class="pullquote"><p>A <strong>Decision Surface</strong> is any point in a system where static logic currently stands in for contextual judgment, and agentic AI makes it possible to restore that judgment at scale. Understanding where Decision Surfaces exist is the first skill of the next era of software.</p></div><div><hr></div><h2><strong>What Is a Decision Surface?</strong></h2><p>A Decision Surface is a structural point in a workflow where one of the following is true:</p><ul><li><p>A threshold was set once and never revisited.</p></li><li><p>A queue is staffed by people doing pattern-matching.</p></li><li><p>A rule bank grew reactively to handle edge cases.</p></li><li><p>An approval step exists that gets rubber-stamped more than 85% of the time.</p></li><li><p>Rich context is available but unused in the decision path.</p></li></ul><p>Here is the distinction that matters: Decision Surfaces are not bugs. They are not technical debt. They are design constraints from an era that has ended. When these systems were built, encoding contextual judgment at scale was impossible. Static rules were the only responsible option. That technological constraint has been lifted. The architecture has not caught up.</p><blockquote><p><strong><span>The Intervention Queue  </span></strong>I worked with a workforce operations platform that manages hundreds of thousands of field employees. Their intervention specialists receive a queue of people to contact each month, prioritized by a static scoring system that weights event severity the same way for every person in every context. A first-year employee with two incidents is different from a 15-year veteran with the same two incidents. The specialist knows this. The system does not. The queue presents data and waits for the specialist to exercise judgment: who to contact first, what to say, how to follow up. That pause, that forced human intervention where the system could reason but does not, is a Decision Surface.</p></blockquote><p>Think about the transition from candlelight to electricity. It did not just make rooms brighter. It restructured how buildings were designed, how cities were planned, how work was organized. Decision Surfaces represent the same kind of inflection for AI. The question is not &#8220;where can we add AI?&#8221; The question is &#8220;where has frozen judgment been limiting what is possible?&#8221;</p><div><hr></div><h2><strong>How to Spot a Decision Surface</strong></h2><p>Decision Surfaces hide in plain sight. They are so embedded in how systems work that the people who operate them have stopped seeing them as decisions at all. Five structural patterns reveal them.</p><h3><strong>1. Rule Banks</strong></h3><p>If/then/else chains that grow and never shrink. The tell: &#8220;We need to add another rule for that edge case.&#8221; The rules are not intelligence. They are a proxy for intelligence that could not exist when the system was designed.</p><blockquote><p><strong><span>From the field  </span></strong>I watched a multi-tenant SaaS platform hit 1,000 data replication rules, one for every edge case they had encountered over years of growth. Each rule was someone&#8217;s careful judgment at the time it was written. Together, they formed a system so brittle that no one could confidently add the 1,001st. The rule bank itself had become the constraint. Not a decision engine. A monument to every past decision.</p></blockquote><h3><strong>2. Hardcoded Thresholds</strong></h3><p>Static values embedded in logic that no one can explain. The tell: ask &#8220;why this number?&#8221; and hear &#8220;that is what it has always been.&#8221; Every hardcoded threshold is a judgment call that was made once and frozen.</p><blockquote><p><strong><span>From the field</span></strong>A multi-tenant platform I worked with had a rate limiter set to the same ceiling for every customer. A $2M enterprise running end-of-month batch processing and a free-tier user running a poorly written script hit the same wall at the same time. The system could not tell the difference because the threshold was set once, uniformly, and never revisited. The platform had the data to differentiate: customer tier, SLA terms, usage trajectory, time-of-day patterns. It just never consulted that data at the point of enforcement. One static number was making the wrong call in both directions. Too strict for the enterprise. Too lenient for the abuser.</p></blockquote><h3><strong>3. Rubber-Stamp Approvals</strong></h3><p>Human review steps with approval rates above 85%. The tell: the human is not deciding. They are adding latency. The patterns the approver uses can be learned. The approver&#8217;s time can be freed for cases that genuinely require judgment.</p><blockquote><p><strong><span>From the field</span></strong>A security team I worked with required manual approval before any new deployment could proceed to production. They approved 90%+ of submissions without meaningful modification. The approval existed because once, years ago, it was the only way to enforce a policy. The dashboard that presented deployments for review was designed to make the human stop and look. But the policy could now be expressed as intent: no secrets in code, no untested dependencies, no breaking changes to shared APIs. And enforced continuously, without the pause. The approval was not adding safety. It was adding days.</p></blockquote><h3><strong>4. Exception Queues</strong></h3><p>&#8220;Manual review.&#8221; &#8220;Needs attention.&#8221; &#8220;Escalation.&#8221; &#8220;Other.&#8221; The tell: your most expensive people spend their time working the queue. Institutional knowledge is being consumed as a resource instead of encoded as an asset.</p><blockquote><p><strong><span>From the field </span></strong>A fintech platform running automated settlements had a reconciliation queue where every mismatch between their internal ledger and their payment processor landed for manual investigation. Their senior ops analysts, the people who understood settlement timing, processor quirks, and currency edge cases, spent 60% of their week working that queue. Each resolution was expert judgment exercised once and discarded. When the analyst left, the knowledge walked out with them. The queue was eating institutional intelligence instead of building it.</p></blockquote><h3><strong>5. Data Available but Unused</strong></h3><p>The workflow has access to rich context it never consults. The tell: ask &#8220;what would your best person do differently?&#8221; and they describe pulling up three other screens. The gap between what the system sees and what the expert sees <em>is</em> the Decision Surface.</p><blockquote><p><strong><span>From the field </span></strong>An identity verification company I advise was building a fraud detection tool. Their scoring system evaluated each identity transaction against a universal threshold. The same one for a consumer banking app and a B2B payments platform. But they had the data to differentiate: transaction patterns, customer segment risk profiles, historical false-positive rates per category. The data was in the system. It was not in the decision path. Their best analyst did this differentiation intuitively. Their system did not.</p></blockquote><div><hr></div><h2><strong>Why Now</strong></h2><p>For decades, the only way to handle complexity in software was to reduce it. Flatten the decision into a rule. Freeze the threshold. Queue the exception for a human. This was not a failure of imagination. It was a rational response to real limitations. You could not ask a rules engine to evaluate tenant history, market conditions, seasonal patterns, and domain expertise simultaneously for every transaction.</p><p>Large language models and agentic architectures changed that equation. For the first time, it is feasible to evaluate rich, multi-dimensional context at the point of decision, at scale, in real time. The cost of contextual reasoning dropped from &#8220;one expensive human per case&#8221; to &#8220;one API call.&#8221;</p><p>But the economics are specific. This is not free and it is not universally sensible. If a deterministic function costs two cents per invocation and an LLM-based judgment costs fifteen cents, you do not thaw every threshold. You thaw the ones where being wrong costs more than thirteen cents. That turns out to be most of them. A wrong fraud decision costs hundreds of dollars. A wrong settlement routing costs thousands. A wrong intervention prioritization costs a preventable incident. The economics favor judgment restoration wherever the cost of being wrong exceeds the cost of reasoning. And the cost of reasoning is falling monthly.</p><div class="pullquote"><p><em>This is not automation. Automation replaces steps. This is judgment redistribution: moving contextual reasoning from expensive, scarce human attention to systems that can exercise it continuously.</em></p></div><p>The locus of judgment is migrating. That migration is the transformation.</p><div><hr></div><h2><strong>How Decision Surfaces Are Reshaping Software</strong></h2><p>The traditional architecture looks like this: design the happy path, handle exceptions with rules, escalate what does not fit, build a dashboard to make the human look at it.</p><p>The emerging architecture looks different: identify the Decision Surfaces, give them context, let them reason, learn from outcomes, surface only what genuinely requires human judgment.</p><p>Three structural shifts are already underway.</p><h3><strong>Rules Become Intent</strong></h3><p>Instead of 1,000 replication rules trying to approximate a goal, a Decision Surface agent receives the outcome statement and reasons toward it. &#8220;Ensure data consistency across tenants with minimal latency, respecting each tenant&#8217;s isolation requirements.&#8221; Rules expressed intent through syntax. Decision Surfaces express intent through context.</p><blockquote><p><strong><span>Lived example</span></strong>That workforce operations platform did not need better prioritization rules. They needed an agent that could receive the intent: &#8220;identify the three highest-impact interventions for this team this month.&#8221; An agent that reasons across employee history, incident patterns, outcome data, and team-specific context to produce a ranked recommendation. They are building it now. It tracks outcomes over time. It learns which interventions actually change behavior. The queue becomes a recommendation engine that gets measurably better every month.</p></blockquote><h3><strong>Queues Become Learning Systems</strong></h3><p>Every item in an exception queue is a decision the system failed to make. When a Decision Surface agent resolves that item, it captures the resolution pattern permanently. When the senior analyst leaves, the knowledge stays.</p><blockquote><p><strong><span>Lived example</span></strong>The settlement reconciliation team did not need faster analysts. They needed a system that classified each mismatch against historical patterns: timing lag, duplicate submission, processor-side error, currency edge case. A system that either auto-resolved with confidence or escalated with a diagnosis attached. The queue transforms from a drain on expertise into a source of compounding institutional intelligence. Each resolution teaches the next one.</p></blockquote><h3><strong>Static Thresholds Become Adaptive Judgments</strong></h3><p>A single threshold applied uniformly is a one-size-fits-none decision repeated at scale. A Decision Surface evaluates each case against current conditions and adjusts.</p><blockquote><p><strong><span>Lived example</span></strong>The identity verification company realized their universal scoring threshold was simultaneously too strict for low-risk segments and too lenient for high-risk ones. It was blocking legitimate transactions in one bucket while missing fraud patterns in another. The Decision Surface was not the score itself. It was the threshold applied to that score. Different segments warranted different lines, drawn fresh for each transaction based on current context. One static number was making the wrong call thousands of times a day.</p></blockquote><div><hr></div><h2><strong>What to Expect</strong></h2><p><strong>In the near term,</strong> organizations that audit their systems for Decision Surfaces will discover they have far more agentic opportunity than they assumed. And almost none of it will be where they were looking. The provisioning pipeline, the reconciliation queue, the cost allocation model: these internal workflows are the hidden gold because they multiply across every customer, every transaction. The companies that move first will compound their advantage because captured judgment improves over time. Delayed competitors face a widening gap.</p><p>The pattern I keep seeing: teams walk into these workshops wanting to &#8220;add AI to the product.&#8221; They walk out realizing the biggest opportunities are in their platform operations. The provisioning logic. The scaling decisions. The routing algorithms that nobody ever thought of as AI-worthy. That internal-first discovery is the most consistent surprise.</p><p><strong>In the medium term,</strong> agent-aware architectures become the expectation, not the experiment. &#8220;Deterministic by default&#8221; gives way to &#8220;judgment-capable by design.&#8221; Software systems become learning organisms in a structural sense, not a marketing-copy sense. Every resolved exception enriches future resolution. Personalized intervention replaces static notifications. Instead of boilerplate messages that say &#8220;an incident occurred, please review,&#8221; systems adapt timing, tone, and content based on what actually changed behavior for this specific person.</p><p><strong>The successor question:</strong> Once judgment moves to agents, the binding constraint becomes trust and identity. Who is acting, on whose behalf, provable how. One company I work with is building what they call &#8220;Know Your Agent,&#8221; applying identity-verification principles to AI agents themselves. When an agent makes a judgment call on behalf of a customer, how do you prove it was authorized, bounded, and auditable? The organizations that solve Decision Surfaces first will be positioned to define the trust infrastructure that makes autonomous judgment safe at scale.</p><p>The question facing every technology leader is not &#8220;should we use AI agents?&#8221; It is &#8220;where has frozen judgment been limiting what is possible, and what happens when we thaw it?&#8221;</p><div><hr></div><h2><strong>Start Here</strong></h2><p>Look at your own systems through the Decision Surface lens this week. Pick one workflow. Run the five tells against it.</p><p>Look for the UI that exists only so a human can pause and decide. Look for the threshold no one can explain. Look for the queue your best people are trapped in. Look for the rule bank that grows and never shrinks. Look for the data that is in the system but not in the decision path.</p><p>You will find more than you expect. You will find it in places no one has been looking.</p>]]></content:encoded></item></channel></rss>