Get in touch

LEAF Advisory + LEAF Labs

Automation built around real workflows.With people in control.

The useful question is not where to add an AI agent. It is how the workflow should run. Some steps are deterministic. Some require interpreting documents, emails or free text. Some need a person to decide.

LEAF works with your business and IT teams to map that process, automate the parts that should be automated and connect models, tools and existing systems through explicit controls, evaluation and human review.

Talk to Us About Your Processes Explore the Workflow
Explicit
workflows
Bounded
agents
Human
review
Observable
runs
Animation: requests move along a workflow through intake, a deterministic rules step and a model step. Confident cases go straight to the systems of record; an uncertain case is routed to a person who approves it before it continues. Every run is traced in an observability panel.

Why AI Automation

Many workflows break exactly where rules meet language.

Traditional automation is extremely effective when inputs are structured and the rules are known. Real business processes, however, often contain emails, attachments, requests written in natural language, incomplete information and exceptions that are difficult to express as fixed logic.

Language models make some of those steps automatable because they can interpret, classify, extract and draft. That does not mean the entire process should become probabilistic.

The architecture should keep predictable work predictable and use models only where interpretation creates real value.

Not everything needs an agent

Use the least complex mechanism that solves the step.

Deterministic where rules are clear. Models where interpretation is needed. People where accountability matters.

  1. 01/ Rule

    Deterministic logic

    Typical steps

    • validate field
    • apply threshold
    • transform data
    • route by known condition
    • call fixed endpoint

    When the rule can be stated precisely, deterministic code is usually the most predictable, testable and economical choice.

  2. 02/ Model

    Interpretation inside a fixed workflow

    Typical steps

    • classify request
    • extract fields
    • summarize document
    • draft response
    • interpret free text

    A language model handles a bounded interpretation step while the surrounding workflow remains explicit.

  3. 03/ Agent

    Dynamic path selection

    Typical steps

    • choose a tool
    • decide which source is needed
    • plan a bounded sequence
    • adapt to a variable case

    An agent is useful when the correct sequence cannot be completely predetermined, provided the available tools and permissions remain bounded.

  4. 04/ Human

    Accountability and exceptions

    Typical steps

    • approve consequential action
    • resolve ambiguous case
    • override recommendation
    • handle policy exception

    Some steps remain human because accountability, uncertainty or consequences make automation inappropriate.

Strong automation architecture is usually a composition of all four, not a choice between them.

TRACEstandardexceptionIncoming requestRULEValidate inputMODELRead & classifyAPPROVALHuman reviewTOOL · API CALLBusiness toolERP / CRM / DBUpdate systemTRACELog + evaluateapproved

Anatomy of an automation

A production workflow is more than a model call.

One case, followed end to end: each step has a type, an owner and a trace.

  1. Trigger

    Trigger

    An email, event, form submission, schedule, message, database change or explicit user action starts the workflow.

  2. Rule

    Validation

    Inputs are checked before downstream systems or models are allowed to act on them.

  3. Model

    Interpretation

    Where needed, a model classifies, extracts, summarizes or reasons over unstructured information.

  4. Tool

    Context

    Enterprise information can be retrieved when a step requires knowledge that is not contained in the triggering input.

  5. Agent

    Decision

    Deterministic rules, model outputs or bounded agent planning determine the next permitted path.

  6. Tool

    Tool execution

    Explicit tools interact with APIs, databases or business applications through defined schemas and permission scopes.

  7. Human

    Human review

    Selected cases pause for confirmation, correction or escalation.

  8. System

    Outcome

    The workflow updates the appropriate system, produces the required artifact or routes the case onward.

  9. Trace

    Trace

    Inputs, decisions, model calls, tools, errors and human interventions are recorded for later inspection.

Fixed or agentic?

The path should vary only when the task requires it.

Fixed workflow

  1. A
  2. B
  3. C
  4. D

Use when

  • the sequence is known
  • rules are stable
  • auditability is important
  • variability is low
  • predictable latency and cost matter

Benefits

  • easier to test
  • easier to debug
  • easier to price
  • easier to govern

Agentic workflow

  1. Goal
  2. Inspect context
  3. Choose permitted tool
  4. Observe result
  5. Choose next step
  6. ↺ repeats within step limits
  7. Stop

Use when

  • the next step depends on the case
  • multiple tools may be valid
  • information availability varies
  • limited planning is genuinely required

Requires

  • tool allow-list
  • explicit scopes
  • step limits
  • timeouts
  • failure handling
  • observability
  • evaluation
  • approval gates where needed

Agentic behavior is an architectural choice, not a maturity level. A fixed workflow is often the better design.

People stay in the loop

Review points are part of the architecture.

Human review should not be added after the automation fails. It should be designed into the workflow where uncertainty or consequences justify it.

Approval before action

Prepare the action automatically but require a person to approve it before execution.

Review uncertain cases

Cases outside the expected confidence or validation range enter a review queue.

Escalate exceptions

Policy conflicts, missing information or unsupported cases route to a named owner rather than being improvised by the model.

Correct and learn

Human corrections can become evaluation data for future versions without allowing production behavior to change autonomously.

Tools, not unlimited access

An agent should never receive more capability than the task requires.

Models do not need unrestricted credentials to enterprise systems. They need explicit tools that expose the smallest capability necessary for the workflow.

Explicit schema

Inputs and outputs are defined.

Permission scope

The tool can perform only the intended operations.

Validation

Arguments are checked before execution.

Error handling

Failures have defined paths rather than becoming unconstrained retries.

Idempotency where required

Operations that may retry should avoid unintended duplicate effects where the underlying system permits it.

Auditability

The automation records which tool was called, with what authorized context and what outcome it produced.

Tool allow-list
  • getCustomer(id)read
  • lookupInventory(sku)read
  • createDraftReply(ticketId)draft
  • createSupportTicket(...)write
  • updateCaseStatus(...)write
  • preparePurchaseOrder(...)write · approval
Fictional examples, shown to illustrate scope. Not LEAF products.

Work with the systems of record

The automation should connect to the process, not create a parallel company.

ERP, CRM, ticketing, email, databases, document systems and internal services already contain the state of the business. Automation should read or update those systems through controlled interfaces rather than creating another disconnected source of truth.

APIs

Preferred where the source system exposes stable, supported interfaces.

Databases

Appropriate for controlled reads or operations designed with the system owner.

Events & queues

Useful when workflows need asynchronous execution or react to system events.

Files & documents

Appropriate when the process begins with forms, reports, attachments or exchanged documents.

Integration platforms

Existing middleware or integration platforms can remain part of the architecture rather than being replaced unnecessarily.

When the workflow needs knowledge

Execution and retrieval solve different problems.

Some workflow steps require information that is not contained in the triggering request. A customer case may need the relevant policy. A technical workflow may need a manual. A document process may need a contract clause.

In those cases, retrieval can provide grounded context to the workflow before a model acts.

Retrieval is not the workflow itself. It is one capability the workflow can call when internal knowledge is needed.

Explore Talk with Your Systems
  1. Workflow step
  2. Needs internal knowledge
  3. Retrieve grounded context
  4. Model acts
  5. Workflow continues

If it runs, you need to see it

Every production run should leave a trace.

A workflow that cannot be inspected cannot be governed. The trace records observable execution state: inputs, outputs, routing decisions, tool calls and human actions. It does not attempt to reconstruct a model's internal reasoning.

Run #1842
  1. 09:41:12Triggertrigger received
  2. 09:41:12Ruleinput validated
  3. 09:41:13Modelmodel.classify → "invoice_exception"
  4. 09:41:14Tooltool.get_order → success
  5. 09:41:14Rulepolicy rule → human approval required
  6. 09:42:51Humanapproved by reviewer
  7. 09:42:52Tooltool.update_case → success
  8. 09:42:52Tracerun complete
Fictional run, for illustration.
Inputs
What entered the workflow.
Model calls
Model and version, relevant configuration and outputs, where the logging policy allows.
Tool calls
Which operation was attempted and its result.
Decisions
Which branch the workflow selected and, where this can be represented, why.
Human actions
Who approved, rejected or corrected an operation, according to the audit model.
Failures
Errors, retries, timeouts and fallback paths.
Outcomes
What was actually written, produced or routed.

Governance is part of the workflow

Someone must own every automated decision path.

Ownership

Define who owns the workflow operationally and who owns each consequential decision.

Approval policy

State which actions can execute automatically and which require review.

Versioning

Models, prompts, workflows, tool schemas and relevant configuration should have identifiable versions.

Data handling

Define which information can be sent to which components and how logs are retained.

Change control

Changes to production behavior should pass through an explicit release process appropriate to the risk.

Audit trail

Automated and human actions should remain inspectable according to the organization's governance requirements.

Test the work, not the demo

An automation is only useful if the complete workflow works.

A model benchmark does not tell you whether a business automation works. Evaluation has to cover the complete path from input to business outcome.

  1. Model step

    Step quality

    Does each model-powered step classify, extract or generate the expected result on representative cases?

  2. Workflow path

    Routing quality

    Does the workflow choose the correct path for normal and exceptional cases?

  3. Tool calls

    Tool correctness

    Are the right tools selected with valid arguments?

  4. Business outcome

    Workflow completion

    Does the case reach the correct business outcome without unintended side effects?

  5. Review

    Human override

    How often do reviewers correct or reject automated decisions?

  6. Dependencies

    Failure behavior

    What happens when a model, API, database or downstream system is unavailable or returns unexpected information?

  7. Versions

    Regression

    Does a new model, prompt, workflow version or connector degrade previously working cases?

Production changes should be boring

Evaluate first. Release second.

A prompt change, model update or tool modification can alter production behavior even when the surrounding application code does not change.

  • Production behavior should not change autonomously.
  • Fine-tuning is not continuous self-improvement by default.
  • Reviewed production outcomes may become future evaluation or training data.
  • New versions are measured against the baseline before promotion.
  1. Collect cases
  2. Update workflow, model or prompt
  3. Run evaluation
  4. Compare with baseline
  5. Review
  6. Release
  7. Monitor
  8. Roll back if required

Monitored cases feed the next cycle

The stack follows the workflow

Decided per step, not by default.

Models

Commercial APIs or privately hosted open-weight models can be selected per task according to quality, language, latency, cost, context, data policy and evaluation results.

Retrieval

Add enterprise retrieval only where a step needs internal knowledge.

Deterministic services

Use ordinary application code, rules and validation wherever they solve the problem more reliably.

Agentic orchestration

Introduce dynamic planning only where the path genuinely varies.

Adaptation

Prompting, retrieval and workflow design should normally be evaluated before introducing fine-tuning. Fine-tuning is an option when evidence shows it addresses a real limitation.

Runtime

Components can run in cloud, private cloud, on-premises or, for suitable workloads, at the edge.

Building blocks

Categories, not a fixed platform. Specific technologies are selected per engagement.

Models

  • commercial model APIs
  • privately hosted open-weight models
  • task-specific models

Orchestration

  • workflow engines
  • application services
  • agent orchestration
  • job queues
  • event-driven processing

Enterprise interfaces

  • REST APIs
  • GraphQL
  • SQL
  • event streams
  • webhooks
  • file interfaces

Knowledge

  • search
  • RAG
  • document retrieval
  • structured queries

Identity & control

  • SSO
  • service identities
  • role-based permissions
  • approval workflows
  • audit logs

Deployment

  • cloud
  • private cloud
  • on-premises
  • edge

Deployment follows the constraints

The workflow does not have to live in one cloud.

Cloud

Managed services and model APIs where data and operating requirements permit them.

Private cloud

Dedicated environments when network, security or organizational boundaries require stronger isolation.

On-premises

Models and orchestration can run inside infrastructure controlled by the organization where relevant requirements demand it.

Edge

Selected workflow or inference components can execute closer to the operational environment when latency or connectivity make that useful.

Explore AI on the Edge

Deployment location does not by itself make a system secure or compliant. Security depends on the full architecture, identities, permissions, data flows and operational controls.

Explore Confidential AI

Where it fits

Look for repetitive work with expensive interpretation.

Intake & triage

Read incoming requests, validate required information, classify the case and route it to the correct process or owner.

Document operations

Extract information, compare documents, prepare structured outputs and route exceptions for review.

Customer operations

Gather account context, prepare responses, update cases and coordinate actions across CRM, ticketing and communication systems.

Back-office workflows

Connect documents, databases and business systems across repetitive administrative processes while preserving explicit approvals.

IT & service operations

Classify tickets, retrieve context, suggest or execute permitted actions and escalate cases that require an operator.

Knowledge-assisted workflows

Retrieve policies, manuals or records inside a larger operational process when the next action depends on enterprise knowledge.

Illustrative patterns, not descriptions of specific client deployments.

Start small enough to measure

The first automation should be bounded, frequent and observable.

Candidate workflows are assessed together with the people who own and run them, on questions like these.

Frequency

Does the process happen often enough to justify automation?

Manual effort

Is significant repetitive work currently required?

Process clarity

Can the current workflow actually be described?

Data availability

Are the required inputs and systems accessible?

Interpretive burden

Is there a step where models genuinely add value?

Consequence

What happens when the automation is wrong?

Reviewability

Can domain experts assess whether outputs are correct?

Integration effort

Can the required systems expose supported interfaces?

Prioritization is a joint judgment with the client team, not a fixed scoring formula.

The LEAF method

Scout. Connect. Unlock.

Advisory identifies which workflows deserve automation, Labs adds the engineering for the pilot and the integration, and Academy prepares the teams who will supervise and work alongside the result.

  1. 01/ Scout

    Map the workflow before automating it

    Work with the people who execute the process today. Map inputs, decisions, exceptions, systems, ownership and pain points. Identify where deterministic automation is sufficient, where interpretation is required and where automation should not be applied.

  2. 02/ Connect

    Build a bounded pilot on real cases

    Co-design the architecture with business and IT teams, integrate the required systems and evaluate the workflow on representative cases with review points already in place.

  3. 03/ Unlock

    Put the workflow into the operating model

    Integrate monitoring, governance, deployment and release processes, then prepare the teams who own and use the automation to operate and evolve it.

One capability, three contributions

Strategy, engineering and adoption have to meet.

Advisory

Identify which process deserves automation, define the operating model and surface the risks and trade-offs with the people responsible for the work.

Explore LEAF Advisory

Labs

Prototype, engineer, integrate and validate the workflow where deeper implementation support is required.

Explore LEAF Labs

Academy

Prepare the teams who will supervise, operate and work alongside the automation.

Explore LEAF Academy

Each engagement combines them as the work requires; they are not separate packages that have to be bought together.

Where automation fits, and where it does not

A bad process does not become good because a model executes it.

The objective is not maximum automation. It is the right amount of automation for a process that can be observed, evaluated and owned.

  • Models make mistakes. Any model-powered step must be designed assuming that incorrect outputs are possible.
  • An unclear process remains unclear. If nobody can explain how cases should be handled, automation is premature.
  • Some decisions should remain human because accountability cannot be delegated to a workflow.
  • Agents are not automatically better than fixed workflows.
  • More autonomy creates more states and failure paths that have to be tested.
  • Tool access must remain constrained to the operations the workflow requires.
  • Poor source data can produce poor automation outcomes.
  • Retrieval can provide context but does not guarantee correct interpretation.
  • Automation does not make an insecure integration secure.
  • Private deployment does not automatically make a system compliant.
  • Fine-tuning does not automatically solve a badly designed workflow.
  • Not every process produces enough value to justify the integration and operating cost.
  • Business outcomes depend on process design, data, systems, people and deployment architecture.

FAQ

Questions & Answers

Common questions about AI Automation.

Ask Us Anything

AI Automation is the design and engineering of business workflows that combine deterministic logic with AI models where a step requires interpretation. LEAF works with business and IT teams to map a specific process, decide where each mechanism belongs, integrate the required systems and validate the complete workflow rather than providing a generic automation product.

Traditional automation is often the better choice when inputs are structured, rules are stable and the sequence is known. Language models become useful when a process contains documents, emails, free text or exceptions that require interpretation. In the systems we design, deterministic steps remain deterministic wherever possible and models are introduced only where they add measurable value.

No. If the sequence is known, a fixed workflow with selected model-powered steps is usually easier to test, observe and govern. An agent becomes useful when the correct next step genuinely varies and the system needs to choose among a bounded set of permitted tools or information sources.

A bounded agent can inspect the current context, choose among explicitly available tools, execute permitted steps and use the results to determine what to do next. Its available tools, permissions, step limits, review points and stopping conditions should be defined as part of the architecture.

Human review is appropriate wherever the workflow is uncertain or an action has meaningful legal, financial, safety, operational or reputational consequences. Common patterns include approval before execution, review queues for uncertain cases and escalation of exceptions to a named owner.

Systems that expose suitable APIs, databases, event interfaces, files or other supported integration mechanisms can potentially participate in a workflow. Typical categories include ERP, CRM, ticketing, email, document systems, databases and internal services. Integration feasibility and permissions are assessed for each engagement rather than assumed from a fixed connector catalogue.

Tools should expose explicit operations with defined schemas and permission scopes instead of giving a model unrestricted system access. Inputs can be validated before execution, consequential actions can require approval and each tool call can be included in the workflow trace.

The workflow can be designed to record observable execution state such as inputs, model calls, tool calls, routing decisions, errors, human interventions and outcomes, subject to the organization's logging and data-handling requirements. Metrics and alerts then make failures and changes in behavior visible.

Evaluation should cover the complete workflow, not only the language model. Depending on the use case this can include model-step quality, routing, tool correctness, workflow completion, human overrides, failure behavior and regression tests on representative cases.

Not by default. Production behavior should normally change through controlled releases. Reviewed outcomes can become evaluation or training data for future versions, but a new model, prompt, workflow configuration or fine-tuned model should be evaluated before it changes production behavior.

Yes. When a workflow step requires internal documents or records, retrieval can provide relevant enterprise context. The dedicated Talk with Your Systems capability covers the deeper architecture for enterprise retrieval, search, permissions and source provenance.

Yes where required by the architecture. Models and orchestration can run in cloud, private cloud or on-premises environments, and selected components can run at the edge where that fits the operational constraints. Confidential AI covers private AI infrastructure in greater depth.

Results depend on the selected workflow, current process quality, available systems, data, integration constraints and deployment architecture. Success criteria should therefore be agreed before the pilot and measured on representative cases from the client's environment rather than assumed from generic benchmarks.

Usually with a Scout Session. LEAF maps candidate workflows with the people who execute them today and assesses value, feasibility, integration effort and risk. A selected workflow can then become a bounded pilot on real cases before wider deployment.

Start with one workflow you can describe.

Show us a repetitive process, the systems it touches, the exceptions your team handles and what happens when something goes wrong. We can map where deterministic automation is enough, where AI could help and where people should remain in control.

Start with a Scout Session Explore Talk with Your Systems