Read the integration boundary

中文 · Exercise

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:

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

{"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.

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.