An AI agent is most useful when it can move a task forward. It is also most trustworthy when it knows which decisions belong to a person.
Across SyntaxLab's demos, agents can retrieve business knowledge, classify email, check appointment availability, create a booking in a sample diary, or propose actions for an invoice workflow. Those examples use different controls: some actions are deterministic, some are simulated, and some stop for a human approval.
Define the action boundary
Before adding tools, list what the agent may read, what it may change, and what requires approval. Searching a public FAQ is different from changing a booking; drafting a reply is different from sending it; extracting an invoice is different from releasing a payment.
Tool schemas should be narrow, and the application should validate identity, permissions, and arguments each time. A model's decision to call a tool does not grant permission to perform the action. OpenAI's function-calling guide describes tool calls as requests that the application executes and returns to the model. OpenAI function calling
Make the handoff useful
A handoff should include the user's request, facts gathered so far, sources consulted, actions already completed, and the specific unresolved choice. “Need human help” is not enough context for a team to take over smoothly.
Recover from tool failures
If availability lookup fails, the agent should not invent open slots. If a knowledge search returns nothing, it should not guess a policy. If an approval link expires, it should explain how to restart. Good fallback behavior is part of the workflow design.
Project evidence
Examples appear in syntaxlab-backend/src/booking-agent.ts, src/workflow.ts, src/inbox.ts, src/chat.ts, and the server-side voice relay. These are demos and prototypes using seeded or visitor-provided data; they do not establish general-purpose autonomous operation or customer deployment.