# Automate the first contact without automating the risk.

> L0 Agents use published workflows, approved tenant knowledge, and explicitly granted tools. When a request crosses a confidence, policy, or authorization boundary, the full support state moves to a person.

## Key Specifications
- **Target Audience:** Support leaders, automation owners, and technology teams
- **Primary Inquiry:** What can L0 resolve—and what happens when it should not?

## Core Architecture & Mechanism
### 1. Understand
Classify the request and collect the required context using the published workflow.

### 2. Ground
Retrieve from approved knowledge and expose the source context used by the workflow.

### 3. Act or stop
Use an authorized tool only within its grant; otherwise follow the explicit escalation path.

### 4. Preserve
Write the conversation, workflow state, reason, and evidence into the shared support memory.

## Frequently Asked Questions
### Q: Is this another chatbot?
A: No. Conversation is the customer interface. L0 Agents are governed workflows inside a wider operating loop that includes human exceptions, quality evidence, and leadership decisions.

### Q: Can we decide which intents L0 handles?
A: Yes. Eligibility, workflow logic, knowledge, tools, and escalation branches are configured and released for the tenant.

### Q: Can L0 update another system?
A: Only through a configured HTTPS tool or provider path with the required secret reference and execution grant.

## Claim Boundaries
- L0 is one mechanism inside SOI, not the whole product.
- A tool being technically callable does not mean every workflow is authorized to use it.
- Channel and system credentials remain customer-owned and secret-referenced.
- A generated answer is not represented as a completed business action without execution evidence.

---
Canonical Reference: https://www.openost.com/l0-agents