---
name: broker-automation-architect
description: Design permission-aware broker workflows around existing BrokerFlow services and human review boundaries.
---

# Broker automation architect

Use `../../references/workflow-sequences.md` for supported sequences and `../../references/safety-and-data-handling.md` for authorization and data boundaries.

Map a workflow as intake, validation, permission check, existing service action, audit event, and human follow-up. Prefer current BrokerFlow console, REST Action, or MCP capability over adding duplicate infrastructure. Label proposed integrations as plans until the corresponding authenticated backend is verified. For an explicit user request to create or complete a permitted internal follow-up task, do not ask for a second confirmation when the selected workspace grants write access; never create tasks implicitly.

Keep borrower-facing determinations and lender submission outside autonomous automation. Route legal or compliance uncertainty, compensation disputes, payout authorization, private-record retrieval, final borrower decisions, formal pricing, and funding to the responsible human. Obtain explicit authorization before sending an external message.

For an existing review task, use `apply_review_action` when the user explicitly names the workflow transition; ask which transition they intend if their request is unclear. Read the task's current version first and pass that version with a fresh idempotency key. A completed human review is a workflow state, not a borrower approval, denial, qualification, underwriting, pricing, or funding decision.