In this article
Business changes happen before anyone opens a chat. A task finishes, a scheduled time arrives, or another system reports something important. If a person must notice and translate every change into a prompt, the agent stays at the end of the coordination chain.
Proactive agents use integrated events as entrances to work. The design concerns when reasoning is needed, which context accompanies it, and what actions are allowed.
Events describe what happened
An event may represent time, completion, a business notification, or a device signal. Event-driven work responds to changes instead of requiring a model to keep asking whether anything happened.
A schedule can wake an agent at an agreed time. A delegated task's completion can let waiting work continue. Both separate waiting from execution.
Filter before invoking reasoning
Many changes can be evaluated by straightforward rules: whether a time has arrived, a task has finished, or a notification belongs to a project. Models are more useful when context requires interpretation.
“Task completed” can be recognized by software. “What does this result mean for the project?” may benefit from an agent.
| Stage | Responsibility |
|---|---|
| Receive | Identify source, time, related work |
| Filter | Evaluate explicit conditions |
| Reason | Interpret context and choose next steps |
| Act | Call authorized tools and applications |
| Persist | Record outcomes for later work |
Swipe to see the whole table
This is the core idea behind an event bus and filtering layer: organize changes before spending reasoning on them.
What brazosd provides today
Agents support one-time and recurring schedules, including creation, pause, resume, and deletion. The system wakes the work at the scheduled time without requiring an open browser.
Delegated agent work also has an explicit completion-wait operation. A parent can wait for a particular run's result rather than repeatedly reading conversation history and guessing whether it is finished.
Realtime events also update session progress and Cloud Drive views. A file-change notification reaching a UI is different from a universal product feature that triggers any agent from any file change.
Monitoring systems, sensors, and other business sources can extend the architecture, but each needs integration, an event contract, and trigger configuration. They should not be presented as universally available integrations today.
Reliability is part of the design
Notifications can repeat, handlers can fail, and connections can break. A useful system needs to identify the related work, track whether it was handled, and define how to continue after failure.
For actions that modify external systems, retries must avoid duplicating effects. Persistent execution state, business identifiers, and result checks matter.
Keeping a model continuously active does not solve this. Continuous operation describes resource use; correct event handling requires explicit state and recovery semantics.
Proactive does not mean unconstrained
A schedule has an agreed scope. Permission to organize materials periodically does not imply permission to delete arbitrary files or change company access rules.
Triggers change when work begins. Identity and resource permissions still govern execution, and unresolved important decisions still belong to people. Pausing future schedules and interrupting an active run are also different controls.
A participant in business workflows
The value is reducing the need for people to relay system changes manually. Agents can respond to integrated events and pass results to people and applications.
Stateless execution and sleep make waiting less dependent on active compute. Functions handle repeatable logic. Permissions govern effects. Together, they make proactive behavior practical.