AL+

Language: RO (română) EN (English)

Email us: paul@alplustech.com

Looking back at the week of 18–24 December 2024

Give the model control only where the path is uncertain

Keep known business steps explicit in code. Use model-directed iteration for uncertain paths, with a clear branching decision, visible progress and a stop rule.

Citiți articolul în română

A business process can contain a difficult judgment without needing a model to invent the whole sequence of work. If the steps are known, keep them explicit. Give a model control over the next step where uncertainty in the path makes that flexibility useful, and define when the exploration ends. The word agent cannot decide that boundary for you.

Looking back from November 2026, Anthropic's Building effective agents, dated 19 December 2024, supplied a useful distinction: workflows follow predefined code paths, while agents let models direct their processes and tool use. The page is mutable and now contains later tooling references. The core distinction is corroborated by Simon Willison's 20 December account; later framework names are not evidence of the December landscape.

Locate one uncertain branch

Consider an illustrative assistant preparing answers to internal policy questions. A known path might receive the question, retrieve the relevant policy, draft a cited answer and pass it to a reviewer. None of those steps needs to become open-ended merely because a language model participates. Code can retain responsibility for their order and for the conditions that permit the process to advance.

The interesting branch appears when retrieval finds conflicting policy versions. A fixed workflow could stop and ask the policy owner. An exploratory agent might instead inspect publication dates, follow links to superseding documents and request clarification if the conflict remains. The architecture decision concerns who selects that next investigative step. It is narrower than deciding whether the whole application is an agent.

Write the branch condition in observable terms. For example, two retrieved documents might make incompatible statements about the same eligibility rule. A vague instruction to research when needed leaves the system without a clear account of why it changed paths. An explicit condition helps an operator understand the transition and inspect whether the model treated an ordinary answer as an invitation to keep searching.

This scenario is a proposal, not an implemented AL+ system or a claim about measured answer quality. Its purpose is to expose the decision hidden by a broad label. A model can participate inside a deterministic sequence, and a mostly explicit workflow can contain a bounded exploratory segment.

Known steps have useful operational properties

When steps are explicit, a team can name where work failed. A missing document, an invalid citation and an unavailable reviewer are different conditions. The application can route each to an appropriate recovery path. Allowing the model to improvise around all three may make a demonstration more fluid while making production behavior harder to explain.

An explicit path also supports clearer changes to business rules. If every answer needs approval before distribution, the approval step can remain in code while prompts evolve. The organization need not rely on the model remembering to ask. This is a control-flow recommendation; permission to read or modify a particular system remains a separate question.

The business consequence is predictability for the people who receive unfinished work. A policy owner can deal with a clear conflict rather than reconstructing an indefinite conversation. That can matter even if a flexible agent is capable of trying more alternatives. The useful outcome is an answer or a specific unresolved issue, rather than simply a longer history of activity.

Exploration needs evidence of progress

The strongest case for model-directed steps is a problem whose useful route cannot be enumerated cheaply in advance. Investigating an unfamiliar document collection can reveal a reference that changes the next search. Hardcoding every possible discovery might cost more than allowing bounded exploration. A workflow that stops at every unexpected reference can also impose excessive work on the user.

That flexibility should remain tied to observable progress. In the policy example, finding an authoritative replacement document is progress. Restating the same conflict in different language is not. Require the exploratory segment to retain the supporting source and the reason it changes the answer. Otherwise repeated tool activity can look productive without reducing uncertainty.

Define a stopping condition before allowing iteration. A proposed rule could stop when an authoritative policy resolves the conflict, when the allowed investigation budget is exhausted or when resolving it requires a decision by the policy owner. The budget is a chosen product constraint, not a number inferred from Anthropic's article. No universal iteration count is established here.

Reaching the limit should produce a useful handoff. Preserve the original question, the conflicting passages and the remaining uncertainty. Do not turn an exhausted budget into a confident answer. A clear unresolved result can be the correct completion of the investigative segment even though the business question still needs a human decision.

Keep uncertainty from spreading across the process

An agent that resolves a source conflict need not decide who may publish the answer or whether to notify everyone. Return its evidence to the explicit workflow. The surrounding application can validate required fields and retain the established review step. This keeps the flexible part connected to the reason it was introduced.

There is a cost to that boundary. A tightly constrained segment may miss a useful route outside its allowed sources or tools. The remedy is to review the constraint against real failures and expand it deliberately when justified. Automatically granting broader control because one investigation stalled turns a local limitation into an unexamined redesign.

For an AI agent project, draw the known sequence first and circle the branch whose next step is genuinely uncertain. State what evidence permits leaving that branch and what ends it unresolved. This differs from choosing tool permissions or approving a coding specification: it assigns ownership of the path itself. Begin with the smallest uncertain segment, then judge whether its flexibility produces an answer people can inspect and use.