DEV Community: Dimitrii Khristoforidi

How We Decide What NOT to Automate

Dimitrii Khristoforidi — Fri, 28 Aug 2026 14:50:43 +0000

A follow-up on building an AI copilot for freight dispatch

TL;DR: We don't decide whether to automate a task based on how repetitive it looks. We look at four things: how much the right decision varies between real-world cases, the cost of being wrong, whether the task’s value comes from speed or judgment, and how quickly a wrong output would be detected.

Together, those determine whether our AI dispatch copilot should suggest, ask for confirmation, act autonomously, or stay out of the way.

Automation is not the default win condition

There's an assumption baked into a lot of AI product thinking right now: if a task can be automated, it should be. Manual is friction, automation is progress, ship it.

We don't work from that assumption anymore. Not because automation is bad - obviously most of what we build is automation - but because treating "can we automate this" as the only question skips the one that actually matters: should this specific task be automated, given what happens when it's done wrong, and how often "wrong" looks different each time.

That second part - how often "wrong" looks different - turned out to be the real hinge. A task can be low-stakes and still be a bad automation candidate if every instance of it is weird in its own way. And a task can look scary and still automate well if the failure mode is boring and consistent.

The four questions we actually ask

We stopped trying to have one big "automation philosophy" and instead run four concrete questions per feature. None of them require ML expertise. They require someone who understands the actual operational process and is willing to ask honest questions about it.

1. How much does the right decision vary from one instance to the next?

Extracting predefined fields from a rate confirmation can be relatively consistent once the prompt and extraction logic have been properly refined. In practice, reaching that level of consistency may require several rounds of prompt improvement and validation. Even then, the task is not entirely straightforward: the total may combine linehaul, fuel surcharge, accessorials, different currencies, or handwritten adjustments.

High-variance tasks are different. Negotiating detention time with a broker who's annoyed about a missed appointment involves interpreting tone, the history with that broker, and how much leverage the carrier actually has that week. Two instances of what appears to be “the same task” can therefore require completely different judgment calls.

Low decision variance → a potentially good automation candidate, provided the inputs are reliable, the output can be validated, and failures are detectable.

High decision variance often means the task cannot be made reliably automatable through prompt engineering alone. It may require richer context, structured rules, specialized tools, historical data, or human review to handle different scenarios consistently.

2. What does a wrong output cost, and does the cost scale with volume?

This sounds like the reversibility question from our earlier post, “Where Should an AI Agent’s Autonomy End?”, but it's slightly different — it's about whether errors compound. Auto-flagging a possible detention clause mismatch that turns out to be a false positive costs a dispatcher thirty seconds of annoyance. Auto-sending a rate counter-offer that's off by a meaningful margin, at volume, across dozens of loads a week, doesn't just cost thirty seconds each time - it can quietly damage a broker relationship you didn't even know was at risk until the relationship is already gone.

Even small errors create operational costs, and those costs accumulate as volume grows. Some errors scale roughly in proportion to the number of occurrences, while others create disproportionate or delayed damage by eroding trust, reputation, or a counterparty’s willingness to work with you again.

3. Is the value of doing it mostly about speed, or mostly about judgment?

Some manual tasks are slow because nobody's built the tooling yet - that's a straightforward automation opportunity. Others are slow because they require judgment, and the slowness isn't the bug; it's the mechanism by which a human catches something a faster process would have missed.

Confusing these two is probably the single most common mistake in early-stage automation decisions: “this takes a dispatcher ten minutes” gets read as “this is inefficient” instead of “this is where the actual thinking happens.”

4. How quickly and reliably will we detect a wrong output?

A reversible error is only safe if someone notices it in time. Some failures become obvious immediately — through a validation check, a dispatcher catching the issue, or a product metric moving in the wrong direction. Others may surface only days or weeks later, through a damaged broker relationship, a lost customer, or a pattern of operational friction that is difficult to trace back to a specific automated decision.

This matters beyond the product itself. An incorrect output can affect how a dispatcher communicates with a broker and, if it goes unnoticed, influence the relationship between them.

The longer and less reliable the feedback loop, the less autonomy we should give the system.

This is also how we think about agent autonomy: it's not a property we give an agent once. It's something we earn task by task.

Autonomy should be earned per task, not granted to the agent as a whole.

That's why we don't think about an AI copilot as simply being “autonomous” or “not autonomous.” Different tasks can - and should - have different levels of autonomy.

We start with decision variance and failure cost, then adjust the level of autonomy based on how much judgment the task requires and how quickly and reliably failures can be detected.

That's the approach we're taking with LoadConnect, our AI dispatch copilot for freight teams.

A framework, roughly

We use decision variance and cost-if-wrong as the first pass — effectively a 2×2 for determining the initial level of autonomy:

Low variance + Low cost if wrong → Automate freely
Low variance + High cost if wrong → Automate + confirmation
High variance + Low cost if wrong → Draft / suggestion + human finalizes
High variance + High cost if wrong → Keep manual

The matrix is only the first pass. Whether the task’s value comes primarily from speed or judgment acts as a separate filter: if judgment is central to the task, we lower the level of autonomy by one step.

Detection speed is another. Even a low-cost, reversible failure deserves less autonomy if we are unlikely to notice it quickly and reliably.

In practice, these autonomy levels map to different system designs. “Automate freely” still means validation and logging. “Automate + confirmation” means generating a structured action but requiring explicit dispatcher approval. “Draft / suggestion” means the model can prepare the response but cannot execute it. “Keep manual” means AI may retrieve context or summarize information, but the actual decision remains outside the agent.

The more autonomy we give a task, the more explicit its validation, logging, and failure signals need to become.

The goal isn't maximum automation. It's the right level of automation for the task.

The high-variance, high-cost category is smaller than people expect. But it is also where the “automate everything” instinct can do the most damage. These tasks often look repetitive and well-defined from a distance, but become much less predictable once you examine real-world cases and the consequences of getting them wrong.

An example that goes the "wrong" way on purpose

Most of what I write about tends to be examples where we correctly chose not to automate something. It's worth including one where we got it wrong first.

Early on, we built a feature that automatically sent a standard response when a load’s pickup window changed slightly — a templated “here’s the updated appointment, please confirm” type of message. On paper, it looked like a low-variance task: a time changed, so send an update.

In practice, the reasons behind those pickup window changes turned out to be far more varied than the template assumed. Sometimes the change was routine. Other times, it signaled a larger issue with the shipper that the dispatcher needed to address directly rather than paper over with an automated message.

We had measured variance at the surface of the task — a timestamp changed — instead of at the level of the decision underneath it, where the real variation was.

Surface-level variance ≠ decision-level variance.

We walked the automation back to a suggestion the dispatcher reviews before sending, rather than an auto-send.

The lesson wasn't "don't automate messaging." It was: **measure variance at the level that actually matters, not the level that's easiest to measure. **A timestamp is easy to check for variance. The judgment call underneath it isn't, and that's usually the one that counts.

What this costs us

Being disciplined about this has a real cost, and it's worth naming instead of glossing over: it means shipping fewer flashy "the AI just does it for you" features than we technically could. Some AI demos look more impressive because they auto-execute actions that we deliberately keep behind a confirmation step.

We've made peace with that trade. A demo that auto-books a load looks great in a thirty-second clip. It looks a lot worse the first time it books the wrong one, and in freight, that first time is a phone call and a canceled contract, not a bug report.

The checklist, if you want to steal it

Before we automate a task fully - not just assist with it, actually remove the human step - we want honest answers to:

If we sampled a representative set of real instances — including rare and high-impact edge cases — would they require essentially the same decision, or are meaningfully different situations hiding under the same label? Are we measuring variance at the level of the actual decision, rather than just the surface of the task?
Does a wrong output stay a small, contained mistake, or can its financial, operational, or reputational cost compound as volume grows?
Is the current “slowness” of this task mostly wasted motion, or is it where a human is actually doing the hard part?
If the system gets this wrong, how quickly and reliably will we know — and who is likely to notice first, us or the customer?

That last one matters more than it sounds. Some bad automation decisions surface immediately, in your own metrics. Others surface three weeks later, in a broker's inbox, and by then it's not really a product decision anymore - it's damage control.

Closing thought

"What should we automate" gets asked constantly in AI products right now. "What should we deliberately not automate, and why" gets asked a lot less, and it's usually the more useful question - because it's the one that forces you to actually understand the task instead of just measuring how often it repeats.

What's one task your team has deliberately kept human-in-the-loop - and what made you decide not to automate it?

Where Should an AI Agent's Autonomy End?

Dimitrii Khristoforidi — Fri, 14 Aug 2026 12:13:38 +0000

Notes from building an AI copilot for freight dispatch

TL;DR: Every few weeks, another "AI agent" launches that can act on someone's behalf — booking things, sending things, updating things. The interesting engineering question isn't "what can it do?" It's "where should we draw the line, and why?" This post is about how we thought through that line while building the AI assistant inside LoadConnect, a dispatch tool that helps truck carriers and dispatchers analyze loads, rate confirmations, and carrier information.

The wrong question

When people talk about AI agents, the conversation usually starts with capability.

Can it read a document? Fill out a form? Call an API and take an action without a human in the loop?

That's a fun question to build for. It's also, in my experience, the wrong first question.

A more useful question is: what does the agent have access to, what can it do with that access, and what happens when it gets something wrong?
These are related, but they're not the same thing:

Capability - what the model can understand, generate, or reason about.
Access - what data, sessions, and systems the agent can technically reach.
Autonomy - what the agent is allowed to do with that access without human confirmation.

You can have a highly capable model with almost no autonomy - it analyzes and recommends, but never acts. You can also have a relatively simple system with dangerously high autonomy because it can make changes on its own.

So the risk profile isn't determined by model capability alone. It depends on the combination of access, autonomy, likelihood of failure, and potential impact.

Two axes, not one

Capability still matters, but it's not the main architectural lever we can control. For the system we were building, the most useful way to reason about risk was to map access and autonomy separately:

Low Access + Low Autonomy → Low Risk
Low Access + High Autonomy → Moderate Risk
High Access + Low Autonomy → Moderate Risk
High Access + High Autonomy → High Risk

The dangerous quadrant isn't necessarily "highly intelligent AI." It's a system that combines broad access with broad autonomy.

Capability affects how well an agent can perform a task - and how sophisticated its mistakes might be. But access and autonomy determine how far those mistakes can propagate.

A highly capable model with access limited to a single document and no ability to take external actions has a relatively small blast radius. A much simpler system can become significantly riskier if it can access sensitive data and make irreversible changes without confirmation.

That distinction became one of the most useful mental models for us when deciding what our assistant should - and shouldn't - be allowed to do.

Why this isn't abstract in freight

Dispatch is a good stress test for this idea because the cost of a wrong autonomous action is immediate and expensive. If an agent misreads a rate confirmation and books the wrong appointment window, that's not a UX bug - it's a missed delivery, a detention fee, or even a damaged relationship with a broker.

So when we were designing the AI assistant, "what should it be allowed to decide on its own" wasn't a philosophical question - it was a product requirement with real financial consequences.

Consider a rate confirmation. Before signing or otherwise accepting the final terms, the dispatcher reviews it to verify that it matches the negotiated load. The assistant helps with the understanding part - extracting the rate and mileage, calculating RPM, flagging detention terms, catching inconsistencies between the document and the load details, summarizing what deserves attention. It does not touch the commitment part - it doesn't accept the load, message the broker, change the appointment, or modify the booking on the carrier's behalf.

The distinction isn't about whether the model could technically perform those actions. It's about whether the system should give the model the permissions required to perform them. We want the assistant to reduce the work required to make a decision - without quietly becoming the decision-maker.

That split turned into two separate design decisions we now make independently for every feature:

What information does this feature actually need to see to do its job - not what would be convenient, but the minimum required.
What is the agent allowed to do with what it finds - surface it, or act on it?

Treating these as one decision ("give it access and let it be smart about the rest") is, in my opinion, where most agent projects get into trouble.

Access: a deliberately narrow scope

The basic architecture is intentionally boring:

User selects a document or load
↓
Relevant content is extracted
↓
Scoped AI task is created
↓
AI analyzes the available information
↓
Recommendation / result is returned
↓
Human decides what happens next

The important part is what isn't in this flow. The agent doesn't get access to the user's authenticated browser session, cookies, or credentials. It doesn't continuously observe other tabs or websites. It doesn't have a general-purpose action layer that can execute arbitrary changes.

A simplified permission model looks more like this:

AI Assistant
├── Read selected document
├── Analyze extracted data
├── Calculate relevant metrics
└── Recommend an action

✕ Access credentials
✕ Read unrelated browser sessions
✕ Monitor activity in the background
✕ Send external messages
✕ Book or modify loads
✕ Change external systems

This creates a useful property: even if the model produces an unexpected output, the set of things that output can affect is already constrained by the architecture - not by a rule the model is trusted to follow.

The instinct when building an assistant is to wire it into everything, because more context makes the model perform better in demos. The problem is that "better in demos" and "safe in production" can pull in opposite directions. The rule we settled on is simple to state and annoying to actually follow: an agent should only touch what its current task needs, for as long as the task requires it. No background processes, no session or credential access, no cross-site visibility, no accumulating data "because it might be useful later."

None of this is exotic security engineering - it's mostly saying no to permissions during the design phase instead of restricting them with policy afterward. Saying no early is a lot cheaper than walking back scope creep once a feature ships and people depend on it.

Autonomy: think in terms of blast radius, not just error rate

The second axis is where it gets more interesting, because autonomy is about trust as much as it is about architecture.

There's a meaningful difference between an agent that says "this rate confirmation has a mismatched detention clause, you should look at it," and one that silently updates the record itself. Both use the same model. Both might even be equally reliable most of the time. But only one of them leaves a human in a position to catch the cases where the model is wrong before that mistake becomes a real-world consequence.

Not every model error has the same consequence, so it's worth separating capability from what happens when that capability fails:

Extract information → Misreads a rate → Incorrect recommendation
Calculate RPM → Uses the wrong mileage → Poor dispatch decision
Flag a contract issue → Misses a clause → Risk goes unnoticed
Send a broker message → Sends incorrect information → External commitment
Change an appointment → Picks the wrong time → Operational disruption
Book a load → Selects the wrong load → Financial and reputational impact

A wrong recommendation can be reviewed and may be caught before it produces an external consequence. A wrong external action may already have created a commitment before anyone notices. That's why we think about autonomy partly in terms of reversibility: the more consequential or irreversible an action is, the stronger the case for keeping a human confirmation step - regardless of how confident the model is.

A useful rule of thumb that came out of this: analyze → recommend → confirm → execute. The first two steps are where an AI assistant provides real leverage. The last two are where human responsibility stays, on purpose.

That doesn't mean every AI action needs a confirmation dialog - low-risk, reversible operations can often run on their own. But when an action creates an external commitment or is hard to reverse, the default should be human confirmation. The question isn't "can the model do this?" It's "what happens if the model is wrong and nobody stops it?" That question changes the design discussion considerably.

In our case, it led to a deliberately conservative boundary: the agent analyzes, flags, and recommends. It does not approve, execute, or take ownership of an outcome, because accountability must remain assigned to identifiable people and organizations; it cannot be delegated to the model. If something goes wrong, "the agent decided" isn't an answer anyone in freight - or honestly, anywhere - is going to accept.

A framing that's helped more than any specific rule

The framing we kept coming back to, especially when a new feature request tempted us to expand scope, was this: don't build a system that's secure because of policy - build one where the risky thing simply isn't possible by design.

A policy says "the agent shouldn't do X." Architecture should make prohibited high-impact actions unreachable by the model, while policy, authorization, monitoring, and data-handling controls address the remaining risks. It's a more boring way to build software. It's also a lot more resilient, because it doesn't depend on every future engineer remembering the rule, or every prompt update preserving the guardrail.

Questions worth asking before you widen an agent's scope

If you're building an AI agent right now, here's roughly the checklist we run through before adding a new capability:

What does the agent actually need to see? Does this feature require a new data source, or would access simply be more convenient?
What's the blast radius if it gets this wrong? A bad recommendation, or an external commitment?
Is this analysis or action? Are we asking the agent to understand something, or to change something?
If it's an action - is it reversible? The harder it is to undo, the stronger the case for human confirmation.
What's the minimum permission required? If the feature works without credentials or persistent sessions, don't add them "just in case."
Do we need this access now, or are we adding it for a possible future use case? If it's the latter, don't add it yet.

The goal isn't to make an agent incapable of doing useful work. It's to make the boundary between what the agent can understand and what it can change explicit - as a product decision, a security decision, and an architectural decision, not something left to a prompt.

None of these questions require exotic tooling to answer. They mostly require being willing to say no to your own feature ideas, which is the actual hard part.

Closing thought

The capabilities will keep expanding. The boundary shouldn't have to move at the same speed.

What an agent can do will keep getting more impressive every quarter. What it should be allowed to do on its own is a much slower-moving, much more durable question - and it's the one that ultimately determines whether people trust the system enough to let it near their real work.

I'm curious how other teams building AI agents are drawing this line internally — especially in domains where a wrong autonomous action has a real, immediate cost. Happy to compare notes in the comments.