Use agents and approvals#
PacketChat agents package instructions, a model selection, permissions, and knowledge bindings into a reusable published version. Runs always use the published version, so editing a draft does not change existing behaviour until it is published again.
Before you start#
- Confirm the required provider model is enabled.
- Prepare the instruction text and any knowledge base the run may search.
- Decide which actions require explicit approval.
- Use a test account and non-production endpoints for the first run.
Build and publish an agent#
- Open Agents and create a draft.
- Give it a specific purpose and instructions.
- Select the provider account and model.
- Bind only the knowledge bases and actions it needs.
- Configure the step and action budget.
- Publish the draft.
Publishing creates the version used by later runs. When changing behaviour, publish a new version and run the same acceptance prompt before wider use.
Run the agent#
- Open the published agent.
- Start a run with a narrow request.
- Review the run timeline and any retrieved knowledge.
- If an action requests approval, inspect its destination and arguments before deciding.
- Read the final run status and stored output.
An approval checkpoint pauses before external actions execute. Approving it queues continuation of the same run: the action results enter the model context and generation continues. Rejecting it cancels the run before those actions execute. Review the final status and output after either decision; the recorded approval alone does not prove the action succeeded.
Use the run's cancel control to stop queued, active or waiting work. Cancelling an active run interrupts further execution, but cannot undo an external action the receiving service already accepted. Inspect the action result before retrying.
Code interpreter and runtime MCP actions are not available in the current release even if their controls appear in the builder.
Verify#
- The run records the intended published version.
- The selected model account and owner are correct.
- Bound knowledge produces a known retrieval result.
- Disallowed actions cannot run without approval.
- An approved test action reaches only the expected endpoint.
If it does not work#
| Symptom | Action |
|---|---|
| Draft edits have no effect | Publish the draft and start a new run. |
| Run cannot use a model | Confirm the provider account is active and the model binding is enabled. |
| Knowledge is absent | Bind the knowledge base to the draft, republish, and wait for documents to be ready. |
| Approved run stays queued | Restore the worker and Redis; check the run timeline before retrying an action. |
| An action target is refused | Use an allowed HTTPS endpoint and review the installation network policy. |
Related#
- Chats, projects, and knowledge — prepare shared context.
- Administration — provider and audit controls.