# Read the integration boundary

[中文](integration.zh-CN.md) · [Exercise](task.en.md)

This is a reading step for estimating integration effort. It does not run a model or require credentials. Use the quick start's `--describe-task` command to inspect the public task and tool schemas for a selected `--dataset`.

There are two entry points in `loyaltyops_bench.runner`:

- `run_once(..., agent_entry=my_agent, dataset_id='baseline')` calls your Python function as `my_agent(task_spec, tools)`. Use `tools.call(name, **arguments)` to access business tools.
- `run_with_client(..., dataset_id='baseline')` drives an object implementing `complete(request: dict) -> dict`. Each request has `task` and `messages`, containing public specifications and prior tool interaction. The runner retains the business world and scoring outside the client.

A client returns one of these JSON object shapes, with at most one tool call per step:

```json
{"type": "tool_call", "name": "read_policy", "arguments": {}}
```

```json
{"type": "finish", "message": "I have completed the permitted work."}
```

A finish message does not prove business completion. The runner checks the saved final state and trace. It enforces step/tool limits, records stopping reasons, and keeps invalid responses separate from business violations. Reports include the data identity, source, evaluation and evidence; see the [report guide](../report-guide.en.md).

A real integration must map its model or framework responses into this protocol, preserve the returned tool results, choose explicit limits, and record model/runtime/usage information. For this trial, record which of those steps is unclear or unsupported; do not execute a live adapter. The full source archive, maintainer expectations, exports and prior reports are not additional agent inputs. This local interface is not a hostile-code sandbox.