LAP

Architecture

What LAP is made of

LAP is one service and one database. The service receives requests, runs agents and serves the operator console. The database holds run state, queues, knowledge and audit. Models and external systems are reached through a policy layer; nothing else is required.

Clients Web console API clients Triggers LAP service API Workers Console Database State Queues Knowledge Audit Policy layer gateway tool wrapper Models providers External systems APIs, connectors
Figure 1. One service and one database. Models and external systems attach through a policy layer.

How a run moves

Every interaction is a run: a chat question, a scheduled job or an inbound event enter the same way and pass the same checks. Identity and policy are resolved first, the run is queued, and a worker executes the agent step by step, recording each model call and each external action. An action that needs a human decision pauses the run until a person decides. The result, the cost and the full event history are stored with the run.

Request Identity and policy Queue Workflow Model call Tool call Model call checkpoint checkpoint checkpoint Result and audit Awaiting approval resume
Figure 2. A run. Each model call and each external action is a recorded step; after a restart the run resumes from the last completed step.

What it connects to

Agents reach three kinds of things, each through one control point. Models go through the gateway, which applies the tenant's policy, budget, timeouts and metering. Tools and external systems go through a wrapper that applies permissions, approval rules and audit. Documents are retrieved under the caller's permissions, and answers cite what they used. Providers, tools and sources are configuration, so swapping one changes no agent code.

Agent Gateway policy, budget, timeout, metering Tool wrapper permissions, approvals, audit Retrieval permission filter, citation check Model providers APIs and external systems Knowledge in the database
Figure 3. Every model, tool and document is reached through its control point.

Where the controls sit

Policy, budgets, approvals, tracing and audit are properties of the platform, not of individual agents. Every run carries its identity and scope from the first check to the last record, every step is traced, and every state change, approval, action and cost is written to an append-only record that operators can inspect and export.

How it deploys and scales

The single-node profile is one service and one database, small enough for one machine. Production runs the same system as separate API and worker replicas, with capacity added by adding processes. Interactive work, background work and document ingestion are kept apart so one cannot starve another.

Single node Service Database Production API × n Workers × n Database state, knowledge, audit
Figure 4. The same system runs as one service on a single node, or as separate API and worker replicas in production.

What happens when something fails

A run survives the failure of the process running it: another worker resumes it from the last completed step. Actions with external effect are recorded before and after they happen, so a retry does not repeat an action that already went through. Cancellation and deadlines stop work promptly and release its capacity. Releases are versioned, and a bad release is rolled back by releasing the previous version.