AI Makes Technical Execution Cheap. Judgment Stays Scarce.
More capacity and AI speed amplify delivery. They do not expose why it remains stuck. That requires judgment with roo...
The LLM Will Not Come Back Tomorrow
13 min read
A Model Has No Unfinished Business
19.09.2026, By Stephan Schwab
An LLM can solve a problem it receives, but it does not return tomorrow because an inconsistency still bothers it. Apparent continuity comes from ordinary software and human decisions that store evidence, schedule another run, define a trigger, and decide what remains unresolved. Knowledge workers do more than answer questions: they notice what is missing, carry exceptions across time, and return to problems others prefer to forget.
The model found a problem.
It mentioned the risk in paragraph seven, between a recommendation and a summary. The human skimmed the response, used the recommendation, and moved on. Nobody created a task. Nobody changed a test. Nobody scheduled a review. Nobody asked the model to examine the risk further.
The next morning, nothing happened.
The model did not wake up worried. It did not wonder whether the risk had become an incident overnight. It did not send a message saying, “I keep thinking about that assumption.” It did not keep thinking at all.
That sounds obvious when stated plainly. Yet much of the current replacement fantasy depends on forgetting it.
Invocation Is Not Initiative
An LLM does not begin work because something matters. It begins because something invoked it.
A human asks a question. An application sends a prompt. A scheduler fires. An event arrives. A monitoring rule crosses a threshold. Some ordinary mechanism assembles context and calls the model.
Then the model responds.
The response may contain a plan, a warning, a critique, a fresh question, or a surprisingly original connection. It may choose tools, inspect documents, run tests, compare alternatives, and revise its answer. With enough surrounding software, this can continue for hundreds of steps.
But the first cause still sits outside the model.
Something had to decide that now was the time to act. Something had to identify the available evidence. Something had to define the objective or at least the arena in which an objective could be pursued. Something had to decide when to stop.
Calling that workflow an agent is reasonable. Calling the model self-motivated is not.
Operational autonomy means the system can perform several bounded steps without asking a human for permission each time. Human initiative means noticing that the bounded task is no longer the real task, carrying the concern beyond the current interaction, and choosing to return even when nobody requested another answer.
Those are different capabilities.
Memory Is a Product Feature
If an AI system appears to remember, ordinary software decided what to store and what to put back into context.
An LLM call receives input and produces output. The next call does not inherit a little private notebook containing everything the model cared about last time.
Products create continuity around the model.
They store chat history. They retrieve documents. They maintain customer records. They summarize earlier work. They keep task state in a database. They write architectural decisions into repositories. They schedule future executions. They select which fragments fit into the next context window.
That machinery can be excellent. It can give an agent useful long-running memory and make a workflow feel coherent across days or months.
But memory is not merely storage.
Someone must decide what deserves to survive. A transcript can preserve every sentence and still lose the meaning. A summary can keep the conclusion while deleting the doubt that should have changed it. A task record can say “completed” while the experienced operator remembers that the customer accepted the workaround only temporarily.
The model cannot retrieve context that nobody captured. It cannot restore importance that the summarizer flattened away. It cannot know that a forgotten detail mattered unless something in the current context gives it reason to look.
This is why continuity has to be designed into code, tests, and durable records. Trusting a chat thread to carry responsibility is not a memory strategy. It is optimism with a scroll bar.
A Clear Question Contains Hidden Work
Before an LLM can produce a valuable answer, someone must recognize that there is a question worth asking.
The prompt may be one sentence. The judgment behind it may have taken twenty years.
Why did the margin fall even though sales rose? Why does this customer keep reopening tickets that appear resolved? Why does every feature touching billing take three times longer than estimated? Why did the contract preserve an exception nobody remembers negotiating? Why does the marketing claim make the support team nervous? Why does the software pass every test while experienced developers still distrust the release?
Those questions do not fall out of a language model by magic.
They begin with someone noticing a mismatch between the official story and lived reality. The finance specialist recognizes that revenue quality changed. The support worker hears the same frustration beneath different customer words. The developer feels the architecture resisting a change. The lawyer spots that a harmless-looking clause moves risk in one direction. The editor notices that fluent copy is making a promise the organization cannot keep.
Then that person frames the problem tightly enough for investigation.
The resulting question may look simple because expertise compressed the complexity before the model ever saw it. Treating the answer as proof that the questioner is unnecessary is like firing the doctor because the laboratory produced the blood result quickly.
The machine accelerated the analysis. It did not create the concern that made the analysis relevant.
The Cleaner Solution Was Outside the Question
The agent knew how to use WebDAV. A human remembered when WebDAV had been fashionable enough to become part of his working memory.
I recently needed to publish files from a GitHub workflow to a web server.
The agent produced a reasonable solution. It created the NGINX web server and proposed SSH as the publishing mechanism. The workflow could connect to the host, transfer the files, and put them where the server expected them.
It would have worked.
It also felt like shoehorning a general-purpose remote shell into a job that should have had a narrower interface. Keys, remote commands, paths, permissions, and deployment behavior all became part of a file-publishing mechanism. None of those pieces was individually absurd. Together they made a simple requirement more operationally delicate than it needed to be.
Then I remembered WebDAV from “back then.”
A 25-year-old developer can know WebDAV today. They can encounter it through a cloud service, a network share, a NAS, or an old server configuration. What they cannot have is a professional memory of the period when WebDAV was fashionable. They were a child, if they had been born at all.
That is not an argument that older developers know more and younger developers know less. It is an argument for different histories. Technologies fall out of fashion without losing every use for which they were well designed. Someone who worked through an earlier cycle may retain a solution that no longer appears in the first page of contemporary defaults.
I asked the agent about it. The answer changed immediately: the chosen NGINX setup already had the capability available. We could publish through the protocol designed for remote file authoring instead of constructing a small deployment ritual around SSH. The result was cleaner and less error-prone.
The interesting part is not that WebDAV is always superior to SSH. It is not. The interesting part is that the agent possessed enough knowledge to explain and implement the better fit as soon as WebDAV entered the conversation. It had not offered that solution before.
My memory of an older fashion changed the question. The changed question opened a different solution space. Then the model became useful inside it.
That small episode contains the whole distinction. The model supplied breadth, implementation detail, and fast comparison. Human agency supplied the nagging sense that the first answer was solving the problem at the wrong level. Human memory supplied an unfashionable old protocol that happened to fit the requirement better than the fashionable default.
If I had accepted the first competent answer, the agent would have helped me implement it competently.
Yes, Models Sometimes Volunteer the Problem
An LLM can discover something you did not explicitly ask about, but only inside a search space somebody opened.
The absolute claim would be easy to refute.
Models do sometimes flag adjacent risks. Ask for a code review and the model may notice a security defect outside the changed lines. Ask it to analyze a contract and it may challenge an assumption that was not in the prompt. Give an agent access to logs and a broad diagnostic goal and it may trace a failure to a system nobody suspected.
That is useful. It is one of the best reasons to use these tools.
It is still bounded initiative.
The human or surrounding system selected the repository, contract, logs, tools, permissions, and broad purpose. The model explored within that environment. It did not independently decide to inspect the company because a customer seemed unusually quiet this week. It did not remember a passing remark from three months ago and connect it to today’s support pattern unless that history was preserved and retrieved. It did not return after the task closed because the answer continued to feel wrong.
A coding model may continue the local pattern indefinitely until a human asks whether the pattern itself is wrong. Once the question is asked, the model can become an excellent partner in answering it. The scarce act was recognizing that the existing question had become inadequate.
Discovery inside an invocation is not continuing concern outside it.
Humans Carry Problems Between Moments
Knowledge work includes keeping a problem alive when the organization would prefer to declare it finished.
A developer leaves the desk and keeps turning an awkward dependency over in her mind. An analyst notices that this month’s anomaly resembles a supposedly unrelated event last year. A lawyer remembers the argument behind a clause after everyone else remembers only the wording. An operations worker checks the system again after the dashboard returned to green because experience says the recovery looks too clean.
Humans forget plenty. They miss signals, rationalize bad decisions, and drop concerns under pressure. Human memory is not a database, and romanticizing it would be foolish.
But humans can care that something remains unresolved.
That concern changes attention. It decides which detail gets written down, which question gets asked in the next meeting, which customer receives a follow-up call, and which apparently completed task gets reopened. It survives gaps between formal invocations because it belongs to a person with history, responsibility, curiosity, fear, pride, or professional conscience.
Organizations rely on this constantly while pretending they do not.
The experienced employee who “just knows” that a result looks wrong is often carrying a compressed model of the business built from thousands of prior encounters. The person who asks one inconvenient follow-up question may be performing more valuable work than the system that generated fifty pages of answers.
This is not mystical human superiority. It is continuing ownership.
An Agent Loop Does Not Remove the Author
A scheduled agent can return tomorrow because someone designed tomorrow into the system.
The obvious technical answer is persistence.
Give the agent memory. Run it every hour. Let it watch metrics, read incoming messages, maintain a task list, and escalate anomalies. Now it can come back tomorrow.
Good. Build that when the problem warrants it.
Just name what happened honestly.
A human decided which metrics mattered. A developer connected the data. Someone defined the anomaly threshold, the available actions, the escalation path, and the conditions under which the system should remain silent. A product owner decided that the concern deserved continuing budget. Ordinary software preserved the state and triggered the next model call.
The resulting agent may provide far more reliable follow-up than an overworked human. It does not prove that human agency disappeared. It proves that human agency was encoded into a system.
And encoded concern has boundaries.
The monitoring agent will watch what it was built to watch. The contract agent will revisit the obligations it was told to track. The coding agent will continue the task state that survived into its next context. None of them automatically inherits responsibility for the problem nobody thought to model.
The scheduler can manufacture recurrence. It cannot decide, by itself, what deserves a recurring appointment.
Replacing People Removes Question Generators
When a company removes specialists, it loses more than answers. It loses the people who knew when to become suspicious.
This is the missing line in most replacement calculations.
Management counts documents written, tickets closed, code produced, cases processed, and hours saved. If the model can generate the visible output, the role appears redundant.
The invisible work never enters the spreadsheet.
Who remembered that the supplier’s data becomes unreliable at quarter end? Who noticed that three harmless customer complaints described the same failure? Who challenged the metric because people had started gaming it? Who returned to the temporary workaround six months later? Who asked whether the new automation moved labor onto someone with less power? Who knew that the apparently obsolete manual check was the last defense against an old integration defect?
Those people were not merely producing artifacts. They were maintaining the organization’s capacity to notice.
The one-person AI company concentrates that entire responsibility in one operator. The agents can research, draft, test, compare, and monitor. They can dramatically expand what that person can do. They cannot ensure the person remembers every unresolved concern or recognizes every missing question.
Once the specialists are gone, their questions often disappear before their answers do.
That is why the replacement can look successful for months.
Design for Continuity Without Pretending It Is a Mind
Use AI for exploration and follow-through, then make ownership and memory explicit in the surrounding system.
The practical response is not to keep every role forever or forbid autonomous systems.
It is to stop pretending that a model owns concerns humans never made durable.
For important work:
- Record decisions together with the rejected alternatives and unresolved doubts.
- Turn recurring concerns into tests, monitors, scheduled reviews, and explicit follow-up dates.
- Assign a human owner who can reopen the question when the evidence changes.
- Preserve source evidence instead of trusting summaries to retain every important nuance.
- Ask models to look for missing questions, counterarguments, exceptions, and signs that the frame itself is wrong.
- Treat an agent’s warning as unowned until someone decides what happens next.
- Review what the system is not watching, not only what its dashboards report.
This makes AI more useful, not less.
The model can search far more evidence than one person can hold in working memory. It can compare today’s state with stored history, generate competing explanations, and revisit a question with tireless consistency. Those are real advantages.
They become durable only when the organization knows who selected the evidence, who owns the concern, and what mechanism brings it back tomorrow.
Someone Still Has to Ask Again
The quality of an AI answer cannot compensate for the permanent absence of the next necessary question.
LLMs make answers cheap.
That shifts value toward the work that was always harder to measure: noticing the anomaly, preserving context, choosing the question, challenging the premise, and refusing to let a convenient answer close an inconvenient problem.
An agent can help with every one of those activities after humans define enough of the environment. It can even surprise them inside that environment. What it does not possess is an enduring personal stake that survives the invocation and returns under its own power.
The model will not lie awake. It will not remember to care. It will not come back because the unresolved issue bothered it.
If it returns tomorrow, look for the human decision and the ordinary software that arranged the return.
Then ask the more important question: who notices the problem that nobody arranged for the system to remember?
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Three Ways to Understand a Country
Stefan drives Sophie to the Pacific for two days. The beach is big enough to make her feel appropriately small. Back at the finca the rain keeps th...
The Resignations
Nathan Cole resigns on a Monday morning with two sentences and no argument left in his body. By Tuesday his desk is empty and the company's institu...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- When Everything Is Finally Under Control (28.09.2026)
- AI Makes Technical Execution Cheap. Judgment Stays Scarce. (24.09.2026)
- The LLM Will Not Come Back Tomorrow (19.09.2026)
- The One-Person AI Company Is a Greed Fantasy (15.09.2026)
- Test Production Without Leaving a Mess (10.09.2026)