Enterprise Digital Assistant Prototype

1. Background and My Role

In 2023, an organizational-culture team explored a conversational assistant for internal services, such as meeting-room reservations, employee-information queries, and scheduling coordination. The prototype aimed to connect intent recognition, capability selection, and API execution within a conversation.

I joined for about two months as a P5 backend engineer from the HR technology team while resources were tight. My main work was designing the backend capability model and implementing interface-dispatch logic. This was a prototype, not a claim of a mature autonomous agent platform.

2. Goals and Scope

The framework was intended to recognize intent, match a business scenario, select from a limited set of capabilities, and execute an appropriate API. Knowledge retrieval and business API calls could coexist.

Its main abstractions were scenario, plugin, API, and a separate knowledge-retrieval capability. A meeting-room reservation might involve checking participant count, available rooms, and schedule conflicts before calling a reservation API.

3. Execution Model

The system deliberately constrained capability selection:

Recognize intent
  -> select scenario
  -> select from plugins bound to that scenario
  -> call a mapped API

Knowledge retrieval ran alongside plugin capabilities within the scenario boundary.

Data Model

Three configuration tables represented scenarios, plugins, and APIs. A scenario bound several plugins; each plugin contained several APIs. The scenario limited scope, the plugin grouped a business domain's capabilities, and the API was the smallest executable unit. Knowledge retrieval was modeled as a separate source of capability.

Call Flow

1. Receive a user's message.
2. Match a scenario through intent recognition.
3. Search only the plugins bound to that scenario.
4. Locate a specific API within the selected plugin.
5. Execute the API and return its result.

The dispatch used a strategy-like model: a scenario set the allowed area, plugin mappings selected an interface, and a fixed API mapping performed the call. It combined rules with LLM assistance.

Architectural Limits

This was a strongly constrained, semi-automated agent prototype. It had no common protocol layer like MCP, no planner, no dynamically generated workflow, and no autonomous capability orchestration. Those limits were intentional for a period when LLM intent recognition and prompt design were less reliable.

4. Main Difficulties

The abstraction was harder than the code. The team had to choose a useful scenario granularity, define plugin boundaries, prevent capability scope from expanding unpredictably, and decide what should be controlled by rules versus the model. There were few mature enterprise-agent architecture references at the time.

Intent accuracy varied, prompt-design experience was limited, multi-turn state management was weak, and tool-selection strategies were not mature. The design therefore relied on rules as a backstop. The culture team owned business logic, the HR technology team handled implementation, and scenario and requirement boundaries changed more than once during collaboration.

5. Risks and Responses

Risk	Response in the design
Wrong intent classification	Restrict available scenarios and plugin scope
Capability selection expands too far	Bind plugin groups to scenarios
Wrong API call	Use fixed API mappings
Uncontrolled model output	Let rules define more of the execution path
Confused multi-turn state	Keep the workflow simple

The general principle was to use rules to control boundaries and a model to improve the conversational experience.

6. How I Understand It Today

In today's terminology, an API resembles a tool, a plugin resembles a toolset or domain capability module, and a scenario resembles a restricted skill. The execution path was a fixed workflow. It lacked a standard protocol abstraction such as MCP, a planner, and dynamic orchestration. It was an early, constrained enterprise-agent form rather than a modern general-purpose agent.

7. My Contribution

I participated in the backend capability model, designed the scenario-plugin-API abstraction, implemented strategy-based interface dispatch, helped define interface mappings and capability boundaries, and supported the business scenarios. The period was about two months.

The project reinforced that agent systems can be difficult primarily because of capability boundaries and abstractions, not because calling an API is hard. A planner and a standardized protocol could extend such a design later, but they were not part of this prototype.