Technical note 04 · Agentic workflows
From AI chat to controlled project workflows
How bounded tools, explicit state, guardrails, evaluations, and approval points turn a useful assistant into dependable project infrastructure.
Practical outcome
More work completed with clear limits and accountable review
10 minute read
Definition
An agent is a controlled loop around tools, not an unrestricted chatbot.
A project agent receives a goal, chooses from a small set of allowed tools, inspects the returned records, and decides whether it has enough evidence to answer or needs another bounded step. The useful unit is the complete workflow, including what happens when data is missing or a tool fails.
The first AEC Hub project agent is intentionally read-only. It can retrieve project context, model-derived facts, and project signals. It cannot change the model, send a message, or publish a decision.
The loop
Constrain the run before improving the reasoning.
The runtime derives firm scope on the server, validates tool inputs and outputs against strict schemas, limits turns and concurrent tool calls, and applies timeouts. These controls make failures observable and prevent a request from expanding silently across the workspace.
Scope
Resolve the firm, user, project, and permitted data before the model can call a tool.
Tools
Offer narrow capabilities with typed inputs, typed outputs, and explicit error states.
Bounds
Limit steps, time, concurrency, and available actions for each run.
Trace
Record tool activity and workflow state without exposing credentials or unrestricted data.
A bounded agent run
Goal
Project question
Controlled loop
BoundedCheckpoint
Reviewable output
Human control
Generation and execution should be separate product moments.
A draft can be generated automatically. A consequential action should occur only after the user sees the exact proposed output, has authority to approve it, and deliberately confirms the action. The platform already applies this pattern to reply workflows: draft first, review the exact body, then send and log the action.
Future write-capable project agents should inherit the same rule. Approval is not a disclaimer at the bottom of the screen. It is a state transition enforced by the workflow.
Evaluation
Measure the workflow against the failures that matter.
A useful evaluation set includes normal project questions, missing evidence, conflicting records, ambiguous identifiers, permission boundaries, unsupported requests, and tool failures. Accuracy is only one measure. Teams also need evidence coverage, abstention quality, latency, cost, and the rate at which professionals accept or correct an output.
That feedback turns deployment into a loop: observe, evaluate, improve, and expand autonomy only where the evidence supports it.