Use case

Hand the workflow to an agent.

An agent takes the goal, plans the steps, and works the documents with governed tools: classify, extract, search, redact, convert, under checkpoints you set.

Deploy LM-Kit One Build with LM-Kit.NET
Plans multi-step work Atomic, governed tools Approval checkpoints Runs fully local

The work between systems is still done by hand.

Document workflows cross scanners, mailboxes, ERPs and archives. The steps in between are people copying values, or scripts that break on the first surprise.

  • Swivel-chair work. Skilled staff spend their day moving values between a PDF and a form field.
  • Brittle automation. Template scripts and RPA break on every new layout, and someone maintains the breakage forever.
  • All-or-nothing autonomy. Tools either do nothing without a person or too much without one; the checkpoint in between is missing.
  • Nothing to audit. When a workflow misfires, there is no record of what was read, decided or changed.

A goal in, a governed run out.

The agent brings the plan; the platform brings the rules. Neither works without the other.

01

Goal

The agent receives an outcome, not a script of steps.

02

Plan

It decomposes the work against the tools it is allowed.

03

Act

Each tool call is atomic, permission-checked and logged.

04

Approve

Risky actions pause for sign-off; the rest run through.

Autonomy that survives a security review.

Agents earn production access the same way people do: scoped permissions, sign-offs and a record of what happened.

Permissions

One tool, one decision

Every built-in tool is a single atomic operation with its own allow, deny and risk rules, so policy is precise.

Checkpoints

Human in the loop, by policy

Approval requirements attach to tools, not to hope: redaction, file writes or process execution can each demand sign-off.

Observability

Every step on the record

Plans, tool calls, inputs and results are observable, so a run can be audited and a failure diagnosed.

Tools registered, policy set, goal handed over.

Register the document tools, set the policy, hand over the goal. The same tools run governed on LM-Kit One, reachable over MCP.

DocumentAgent.cs 
using LMKit.Agents;
using LMKit.Agents.Tools;
using LMKit.Agents.Tools.BuiltIn;
using LMKit.Model;

var model  = LM.LoadFromModelID("qwen3.5:9b");

var policy = new ToolPermissionPolicy()
    .AllowCategory("document", "data", "text")
    .RequireApproval("process_*");

var agent = Agent.CreateBuilder(model)
    .WithTools(t =>
    {
        foreach (var tool in BuiltInTools.GetByCategory("document"))
            t.Register(tool);
    })
    .WithPermissionPolicy(policy)
    .Build();

var result = await agent.RunAsync(
    "Split claim-batch.pdf and extract the claim fields.");

Console.WriteLine(result.Text);

The technology underneath.

Every stage of the loop is a documented capability you can inspect on its own.

Plan

Agent reasoning

ReAct-style planning that decomposes a goal against the tools it may use.

How planning works

Act

Tools & function calling

Atomic built-in tools, one operation each, so policy stays precise.

How tools work

Govern

Permission policies

Allow, deny, risk levels and approval checkpoints, declared in a few lines.

How permissions work

Audit

Observability

Plans, tool calls, inputs and results on the record, so a run can be audited and a failure diagnosed.

How observability works

Frequently asked questions.

How is this different from scripting the pipeline by hand?

The agent plans against a goal instead of following a fixed script, so a batch with an unexpected document type reroutes instead of failing. The tools it plans with are the same atomic operations you could call yourself.

What stops an agent from doing something destructive?

Policy, not prompts. Every tool carries allow, deny, and risk rules, and approval requirements attach to sensitive operations like process execution or file writes, so the agent requests sign-off exactly where you demanded it.

Can we see why an agent did what it did?

Yes. Plans, tool calls, inputs, and results are all observable and logged, so a run can be replayed for an audit or a failure diagnosed like any other production incident.

Do the same workflows run as a service?

Yes. The tools run governed on LM-Kit One and are reachable over MCP, so workflows built with LM-Kit.NET in-process and assistants calling the server share one tool catalog and one policy surface.

Private Document Intelligence

Give an agent its first workflow.

Deploy LM-Kit One Agent orchestration in depth