Which Decisions Should an Agent Make?

A database agent usually needs to understand a question, find tables, construct a query, and interpret the result. Asking the model to invent that process on every request adds decisions the application could already have made. Prescribing every detail makes unfamiliar questions harder to handle.

A useful split is for the application to define available stages and transitions, while the model makes decisions that depend on the particular question or data.

Define the workflow

During retrieval, the agent might choose candidate tables and request their structure. During validation, it might propose another check. It should not be able to remove database access restrictions or keep retrying without a time limit.

A state machine can express this workflow. Each state has a handler that receives context, performs work, and returns the next state. A failed validation may return to query generation. An exhausted budget leads to a response explaining what could not be established.

The transitions are also testable. A particular database error should trigger a relevant repair rather than another identical call.

Add concurrency where work is independent

Descriptions of two tables can be fetched at the same time. Query generation that needs both descriptions must wait for them.

Concurrency also needs a policy for a branch that fails or finishes late. Partial results are useful only when they are sufficient for the answer. Spawning several agents does not solve the problem of combining their outputs.

Start with a process you can describe and follow in an execution trace. Add model decisions where a fixed rule repeatedly falls short. Each of those decisions then has defined inputs, a budget, and a way to check the result.