Config Agent
From onboarding spreadsheet to SaaS configuration
An onboarding spreadsheet describes what a business needs configured. Making that configuration real requires a sequence of dependent API operations. I built the agent that connected those steps for a B2B gym-management platform.
Built during my software engineering internship at DxFactor.
Read the spreadsheet
A background task reads the multi-sheet Excel template. Work can be grouped as individual rows, related batches, or virtual tasks.
Load relevant instructions
File Search retrieves the relevant API documentation. A separate tool loads the Markdown instructions for the current operation.
Run dependent operations
Authenticated tools run the operations in order. Persistent state carries returned identifiers into the later tasks that need them.
Validate the result
The system checks responses, retries failures, and records run IDs and logs. Success or failure is reported outside the model response.
A workbook becomes a workflow
The input was a multi-sheet Excel onboarding template. The agent had to understand the data, find the relevant administrative APIs, assemble their payloads, and execute the operations in the right order. Later work could depend on identifiers created earlier.
A Django background task downloaded the file from object storage and ran the agent asynchronously. The orchestration supported individual rows, cross-row batches, and virtual tasks. Those different units let related configuration work stay together.
The useful output was a configured system, not a description of how someone might configure it. Authenticated tools connected the agent to the operations it needed to perform.
Load the instructions the task needs
The agent retrieved relevant documentation from consolidated Swagger and OpenAPI specifications through OpenAI File Search. That gave it the request structure for the operation it was about to perform.
Implementation details
I also built get_modular_prompt, a tool that loaded task-specific Markdown instructions at runtime. Organizations, brands, clubs, memberships, and offers each had their own operational guidance. The main orchestration prompt did not need to carry every detail at once.
This kept the instructions tied to the current workflow. API documentation described the available operations; the task instructions described how those operations fit together. Keeping those responsibilities distinct made the agent easier to inspect and revise.
Keep state between dependent calls
A long operation cannot rely on conversation text alone to remember what happened. The agent used persistent state and explicit state read/write tools to carry information between steps.
Implementation details
It attached authentication, validated responses, recorded run IDs and logs, retried failures, and issued success or failure notifications. These mechanisms made execution visible outside the model response.
The dependency order mattered as much as the individual payload. Creating a configuration entity and using its identifier in a later operation are separate actions, but they belong to one workflow. State connected them without asking an operator to reconstruct the sequence.
Make failure part of the design
Retrieval and tool calling are only part of an operational agent. The system also needs a clear response when documentation is insufficient, a call fails, or a returned value does not validate. Bounded retries and visible failure reporting keep that uncertainty from looking like success.
The result was production software that automated a multi-step onboarding process. I built it from scratch during my 2025 internship. This case focuses on its architecture and behavior; employer data, internal endpoints, and client identities remain private.