From Forms to AI Agents: Redesigning Community Event Workflows with LLM‑Powered Agents

Project Background

Operating a marketing activity traditionally required jumping between three independent systems more than ten times and filling over forty fields manually. The team set out to redesign this workflow using AI, moving from a simple "AI helps you fill forms" approach to a two‑stage Agent plus aggregation console.

First Version – AI‑Assisted Form Filling

The initial solution introduced a five‑step wizard where an LLM (via two Dify workflows) parsed the planning document and pre‑filled fields across the systems. While operation time decreased, the core workflow remained unchanged: humans still drove the process, validated AI output, and navigated between systems.

Irreversible – parsing errors forced a restart.

Black‑box AI – 5‑15 s latency with no real‑time feedback.

Hard‑coded components – limited to one template and five components.

No persistence – progress lost on page refresh.

The key insight was that AI limited to field‑level assistance cannot deliver a qualitative leap; true impact requires AI to drive the entire process, with humans intervening only at critical checkpoints.

Evaluating an Agent‑CLI Approach

The team explored a more aggressive Agent CLI concept, inspired by tools like OpenCode CLI, Cursor, and Claude Code, where natural‑language commands could orchestrate the whole event creation. Three hard obstacles emerged:

Agents lacked concrete business constraints (no "body‑sense").

Agents could not retrieve real‑time status.

Agent actions were hard to audit and explain.

These constraints led to a hybrid approach positioned between fully autonomous agents and pure manual operation.

Choosing LangGraph as the Orchestration Engine

After evaluating several options, the team selected LangGraph (an MIT‑licensed state‑graph engine from the LangChain ecosystem) to define AI workflows. LangGraph provides directed‑graph nodes for LLM calls, tool invocations, or human confirmations, and includes a built‑in checkpointer for persisting session state, enabling interrupt/resume semantics.

Second Version – Workflow‑Centric Architecture

The redesign reframed operators as "process supervisors" rather than executors. The workflow required only two inputs: a link to a Feishu planning document and a final confirmation on AI‑generated structured cards. All other steps—document parsing, topic creation, activity configuration, component assembly—were automated.

A practical rule emerged: if a business process can be expressed as a finite‑state machine, use a Workflow; if it resembles a goal‑oriented problem, use an Agent. Most enterprise scenarios blend both, using Workflow for reliability and Agent for flexibility.

Component Module Protocol and Capability Registry

To handle the growing number of venue components, the team introduced a Capability Registry—a plugin‑like system where each component registers its UI contributions (welcome state, interrupt cards, result display) without the shell needing to know business specifics. This decouples the shell from component logic, adhering to the Open‑Closed Principle.

Key design rules include:

Initialization must be side‑effect‑free; write operations occur only after explicit user confirmation.

Double‑track registration combines explicit selection with conditional injection, allowing new components to be added without modifying core dispatch code.

Declarative positioning lets components declare desired placement (e.g., a vertical Feed should appear at the page bottom) without the component needing to know the actual layout.

Form‑Hosting Runtime – An Engineering Compromise

The component forms rely on a separate sub‑project using the Formily engine, which is incompatible with the main front‑end stack. Rather than rewrite dozens of forms, the team built an isolated runtime that communicates with the main page via a message protocol, preserving existing functionality while focusing development effort on new value (preview interaction, AI assistance, draft sync).

Two‑Stage Architecture

Stage 1 – Activity‑Plan Generation Skill : Read‑only queries retrieve candidate data (budget pools, categories, tags, historical venues) without performing any writes. This mirrors the principle of least privilege.

Stage 2 – Aggregated Workbench : A dedicated page overlays the existing venue builder with an interactive mask, allowing operators to click any component in the preview and edit its configuration. The workbench supports progressive disclosure, asking for minimal information (activity name, time, at least one topic) and then incrementally gathering additional details.

Practical Trade‑offs and Lessons Learned

AI‑Human Division : Full AI control is unrealistic; AI handles information extraction, draft generation, and field suggestions, while code enforces workflow, validation, and side‑effect timing.

Interaction Model : A hybrid of natural‑language intent and structured UI confirmation reduces cognitive load and improves accuracy.

Side‑Effect Control : The interrupt/resume mechanism ensures no writes occur until the user explicitly confirms, preventing dirty data.

Engineering Compromise : Reusing the existing form runtime avoids duplicated effort at the cost of added architectural complexity.

Trust Building : Transparent intermediate cards explain why user input is needed and what AI has already done, avoiding “fake progress bars” that erode trust.

Evolution Across Three Versions

Version 1 : AI pre‑fills fields; humans remain the primary actors.

Version 2 : AI drives the process; humans supervise via card review.

Version 3 : AI also generates the planning document, completing a two‑stage pipeline from idea to venue configuration.

Future directions may include maturing the Agent CLI for more natural‑language operations, extending the architecture to additional business scenarios, or achieving fully AI‑controlled components once LLM reliability improves. Throughout, three principles remain constant: controllable processes, correctness first, and reducing operator burden.