A procedure in a notebook waits for somebody to perform it. A procedure connected to software can inspect an event, prepare a response, check a rule, and change a record. The distance between those two forms of knowledge is becoming easier to cross.
It is also becoming easier to cross badly. A fluent explanation of a process can leave out the detail that matters when the process acts on real people or real money. Turning that explanation into code does not repair the omission. It makes the omission repeatable.
When can a statement of knowledge become a reliable executable workflow? When the knowledge has been translated into explicit inputs, supported actions, acceptance criteria, and ways to handle failure. AI can help with that translation. The reliability comes from the complete system and its evidence, not from the confidence of the generated instructions.
What “executable” means here
Executable knowledge is a practical description for knowledge embodied in a process that can perform work. It may be a small script, a spreadsheet rule, a scheduled check, or an AI-assisted workflow. It does not require a system that independently runs an entire organization.
Consider a rule about confirming appointments. A written instruction says that customers should receive a reminder before the appointment. An executable version needs to know which appointments qualify, which contact address is approved, when the reminder should be sent, whether a reminder has already been sent, and what to do if the appointment changes.
Those details are part of the knowledge. A person may have supplied them informally for years without noticing that they were missing from the written instruction. Software needs them to be represented in a way the process can use.
A reliable workflow therefore includes more than the happy path. It knows what counts as an input, how to distinguish an update from a new event, and which conditions should stop action. It leaves a record that allows somebody to determine what actually happened.
The word “reliable” is always relative to a supported scope. A process may be dependable for routine appointment reminders and unsuitable for deciding whether a vulnerable customer should receive a particular message. Defining the scope is part of building the capability.
Explanation, recommendation, and action are different products
An explanation helps a person understand. A recommendation proposes a choice. An action changes something. Each requires a different standard of acceptance.
An assistant might explain how an appointment process works using a general example. It might recommend sending a reminder after inspecting the actual schedule. It might then send the message through a tool. The third step introduces obligations the first step did not carry.
The message could go to the wrong person, disclose information, repeat an earlier message, or contradict a cancellation. A person may be able to recognize and correct a flawed explanation before using it. An external action can create consequences before anyone notices the flaw.
A useful design keeps these stages visible. It allows the system to prepare a proposed action without silently carrying it out. Where standing authorization permits routine actions, the process still needs to establish that the specific action falls within that authorization.
This distinction also makes incremental adoption possible. A business can first use a tool to prepare draft reminders. After checking representative cases, it can permit sending within a narrow scope. It does not have to choose between doing nothing and granting broad autonomy.
Why AI changes the translation cost
Much operating knowledge arrives in language. People explain exceptions in messages, describe a procedure in a document, or teach a new employee through examples. Traditional software requires someone to turn that material into defined logic and interfaces.
AI can assist that work by identifying repeated steps, drafting a specification, proposing test cases, or producing an initial implementation. It can also help interpret inputs whose wording varies. This can make a small workflow economically plausible where a custom project previously seemed too expensive.
The improvement is a reduction in some development and interpretation costs. It is not proof that every generated implementation is correct. A process still needs inspection, testing, access control, and maintenance. If these requirements overwhelm the useful work, a simpler manual procedure may remain preferable.
Anthropic’s Building Effective Agents distinguishes predefined workflows from systems whose models direct their own tool use. That architectural distinction is useful even though the vendor’s 2024 tooling discussion is now historical. A known sequence may be better represented as a clear workflow than as an open-ended agent.
The most productive question is therefore not “Can AI build this?” It is “Which part benefits from flexible interpretation, and which part should remain a deterministic rule?” That question often leads to a smaller, more inspectable system.
A workflow is a contract with the environment
Before implementing a procedure, define its trigger. Does it begin when a new record appears, when a date approaches, or when a person makes a request? A vague trigger can cause duplicate work or missed cases.
Define the inputs next. Each should have an authoritative source, an expected format, and a treatment for missing values. If the schedule is the authoritative source for appointment time, the system should not substitute a time mentioned in an old email.
Then define the allowed actions. A process that prepares a reminder does not need permission to edit every customer record. A process that checks an invoice does not necessarily need permission to pay it. Narrow actions make the workflow easier to understand and limit the consequences of a mistake.
Finally, define what acceptance looks like. A reminder is complete when the approved message has been sent to the permitted recipient and the event has been recorded. A draft existing in a chat window does not satisfy that definition. A tool reporting success without a durable receipt may not satisfy it either.
The contract should say what happens when the environment violates an assumption. An unavailable source, changed appointment, expired authorization, or ambiguous identity should produce a defined response. Silence and guessing are poor defaults.
Worked example: a document-expiry reminder
Imagine a small organization that must renew several routine documents. This is an illustrative design, not a claim about an implemented Salars system. The organization wants a reminder thirty days before an expiry date, followed by a human decision about the renewal.
The authoritative record includes document name, responsible person, expiry date, source document location, and the date the information was last checked. The workflow reads that record and identifies items inside the reminder window. It does not infer an expiry date from a vague sentence.
For each qualifying item, it prepares a short message that states the recorded date and links to the source. It checks whether a reminder for that document and expiry date has already been issued. If so, it does not send another merely because the scheduled process ran again.
The reminder can be sent under an established internal communication rule. The renewal itself remains a separate action requiring a responsible person. The workflow cannot accept new contract terms or make a payment simply because it found an approaching date.
If the record lacks an expiry date, the system creates a question for the owner instead of inventing a date. If the document has already been renewed, the new date becomes authoritative only after somebody verifies the renewal evidence. The workflow preserves the earlier event so the history remains understandable.
The valuable result is modest: fewer overlooked dates and a clearer handoff. The design deliberately avoids treating a reminder as proof of legal compliance or as authority to enter an agreement.
Test the transitions, not just the final screen
A process can look correct while handling state incorrectly. The reminder may display the right text but send it twice. The record may show a renewal while the supporting document remains unverified. Tests should therefore inspect the transitions between states.
For the document example, useful cases include an ordinary approaching date, a date outside the window, a missing date, a duplicate scheduled run, a changed owner, and a renewal recorded after a reminder was sent. Each case has a defined expected behavior before the test runs.
A test that merely confirms that the workflow ran is weak evidence. A stronger test confirms that the right item qualified, the message used the authoritative date, the duplicate was suppressed, and the unresolved case was handed to a person.
Some checks can be mechanical. Dates can be validated. Required fields can be enforced. Event identifiers can prevent duplicate actions. Other checks require judgment, such as whether a message communicates the right level of urgency without claiming more than the record supports.
The old process provides a useful baseline. If a simple calendar reminder already works well, a complicated agent needs a reason to exist. The new design should solve a demonstrated problem, not merely create an impressive diagram.
Repetition makes hidden assumptions expensive
A person performing a task once may notice an odd case and adapt. A workflow can repeat the same mistaken assumption across many cases. This changes the economics of an error.
Suppose a draft procedure assumes that every customer has one approved contact address. That assumption may be harmless in most records and wrong in a few. If the workflow sends messages automatically, the exceptional records can create repeated disclosure or service problems.
The remedy is to represent the uncertainty rather than bury it. Records with conflicting contact information can be excluded from routine sending until a person resolves them. The process can show how many such cases exist, which helps the business decide whether the underlying data needs improvement.
A recurring exception is information about the organization. It may indicate a missing field, an outdated policy, or a process that never accounted for an important customer type. The workflow should expose that information so the owner can improve the system.
This is where executable knowledge can become more than automation. A well-designed process reveals which parts of the organization’s knowledge are explicit, which are missing, and which need to be updated. A poorly designed process conceals those gaps behind apparent completion.
Keep flexible interpretation away from binding arithmetic
A language model can help explain a calculation, identify suspicious inputs, or draft code that performs it. The final arithmetic should use a defined calculation with testable inputs. A fluent answer should not become the ledger.
The distinction matters even in ordinary workflows. An assistant reading a supplier message may extract a proposed price. The price should then enter a validated field, preserving the source and units. A deterministic calculation can compute the total. A person can review any discrepancy before a purchase commitment.
This approach gives each component an appropriate job. Flexible interpretation handles varied wording. Structured validation checks the extracted fields. Deterministic logic performs the calculation. The authorization layer decides whether the resulting action is allowed.
It also makes errors easier to locate. If the total is wrong, the reviewer can inspect whether the input was misread, the units were wrong, or the formula was incorrect. A single free-form answer makes those causes harder to distinguish.
The later article on Hallucinated Profitability explores this issue for business economics. The general principle is already useful: keep evidence, interpretation, calculation, and commitment visible as different stages.
A maintained workflow is different from a generated artifact
The first implementation is the beginning of responsibility. Sources change, records change, software changes, and the organization changes. A workflow needs an owner who can notice when its assumptions no longer hold.
That owner does not have to inspect every successful routine case. The design can provide a small record of runs, exceptions, and relevant changes. The owner can then review whether the supported scope remains accurate and whether the process still solves the intended problem.
Versioning matters because a result should be traceable to the rules that produced it. If a reminder rule changes from thirty days to forty-five days, the organization should be able to explain why an earlier message used the old timing. A current instruction alone cannot explain the history.
A fallback matters too. If the automated process becomes unavailable, somebody should know how to find the approaching dates manually. A capability that works only while every component behaves perfectly may be less dependable than the simpler process it replaced.
The article Turn Repeated Knowledge Into Software examines when this maintenance burden is justified. Executable knowledge is valuable when the recurring benefit exceeds the cost of keeping the process trustworthy.
The counterexample: when a document should remain a document
Some knowledge is better kept as guidance. A sensitive conversation, an unusual negotiation, or an evolving creative judgment may not have stable inputs and acceptance criteria. Forcing it into a workflow can distort the work.
A manager’s guidance about handling an upset customer may help staff understand the organization’s values. That does not mean a model should independently decide what promise to make in every conflict. The consequences and context may require a person who can take responsibility.
Another counterexample is an infrequent task. If the procedure occurs once a year and changes each time, a clear checklist may be cheaper and safer than maintained software. AI can still help prepare the checklist without turning it into an autonomous process.
The relevant threshold is not whether automation is technically possible. It is whether the task is stable enough, repeated enough, and inspectable enough to justify implementation. Leaving a task manual can be a sound design decision.
AI Leverage in Practice
Choose a procedure that repeats and has a low-consequence starting scope. Write a one-page contract: trigger, authoritative inputs, allowed actions, accepted result, exceptions, owner, and fallback. If important details cannot be filled in, resolve them before asking a tool to implement the process.
Use AI to draft a specification and propose counterexamples. Inspect that material yourself. Include cases that should produce no action, because a workflow’s restraint is often as important as its completion rate.
Implement the smallest useful version. It may read records and prepare drafts without sending anything. Compare its outputs with the existing process using representative cases. Add authority only when the evidence supports the specific expansion, and enforce the boundary in the tool or downstream system.
Today’s tools can help turn repeated knowledge into scripts, rules, and bounded workflows. Future systems may manage larger parts of that translation and maintenance. That prospect does not remove the need for an owner, evidence, and a way to stop the process today.
Retain the specification and tests with the implementation. When an input source or rule changes, rerun the relevant cases. If the workflow becomes harder to check than the original task, narrow it or return to the simpler procedure.
Knowledge that can act responsibly
Executable knowledge connects what an organization knows with what it can do repeatedly. Its promise is lower friction between understanding a useful procedure and putting that procedure to work.
Its risk is equally concrete: an incomplete understanding can become an active system. The safeguards are therefore part of the capability itself—clear inputs, bounded actions, observable results, supported exceptions, and maintenance tied to actual change.
This completes the opening movement of The Age of AI Leverage. Cheaper information allows more attempts. More accessible cognitive assistance expands what can be explored. Executable knowledge begins to turn those attempts into productive systems. The next question is whether those systems deserve to be called capital.
Sources
- Anthropic, Building Effective Agents, December 2024 architectural distinction between predefined workflows and model-directed agents; the page notes subsequent tooling changes.
Loading comments…