I recently built and tested an LLM-powered employee onboarding agent locally using Python, GitHub, and the Groq API.
The goal was to understand how an AI agent can combine an LLM with tools, structured data, workflow rules, and human approval to complete a practical business process.
What the Agent Does
The onboarding agent follows a tool-using workflow:
• Retrieves an employee profile from mock HR data
• Checks the employee’s compliance status
• Sends a compliance reminder when required
• Requests human approval when compliance is pending
• Provisions role-based access after approval
• Sends a welcome notification
• Completes the onboarding workflow
The project uses mock HR and compliance data, so access provisioning and notifications are simulated locally.
Technical Architecture
The agent orchestration runs locally, while LLM inference is handled through the Groq API.
Local Python Agent
↓
Employee Profile Tool
↓
Compliance Check Tool
↓
Notification Tool
↓
Access Provisioning Tool
↓
Groq API
↓
LLM Response
↓
Agent continues the workflow
This helped me understand an important distinction: the agent orchestration and tools can run locally, while the actual LLM inference can be provided through a remote API.
ReAct-Style Tool Calling
The workflow follows a ReAct-style pattern where the model determines the next action, selects a tool, receives an observation, and continues the workflow.
For a pending-compliance employee:
Get employee profile
↓
Check compliance
↓
Compliance = PENDING
↓
Send reminder
↓
Ask for human approval
↓
Approval received
↓
Provision access
↓
Send welcome notification
↓
Complete
For an employee whose compliance is already cleared:
Get employee profile
↓
Check compliance
↓
Compliance = CLEARED
↓
Provision access
↓
Send welcome notification
↓
Complete
This difference was useful for validating that the compliance state actually controls the agent’s behavior.
Engineering Work
During the project, I worked through the complete development workflow:
• Installed and verified Git and Python
• Created an Ed25519 SSH key
• Configured the Windows SSH agent
• Connected the SSH key to GitHub
• Forked and cloned the repository
• Configured origin and upstream remotes
• Created a dedicated development branch
• Created a Python virtual environment
• Installed project dependencies
• Ran the agent’s dry-run validation
• Connected the agent to Groq
• Tested the agent end-to-end
• Committed and pushed the changes
• Opened a pull request
Fixing a Model Compatibility Issue
During the first real agent run, I encountered a Groq API error:
The model “llama-3.3-70b-versatile” was no longer available, resulting in a 404 model_not_found error.
I verified the models available through the API and updated the agent to use:
openai/gpt-oss-120b
I also moved the model selection behind a single GROQ_MODEL constant instead of leaving the model identifier hardcoded.
This was a useful reminder that LLM integrations have dependency-management concerns just like other API integrations. Model identifiers and provider availability can change and break an otherwise working application.
Adding a New Test Scenario
The first task was to add a new employee:
EMP-2026-0849
Arjun Reddy
Software Engineer
L4
Platform Engineering
The employee was added to the mock HR database with a CLEARED compliance record.
I then ran the dry-run validation and executed the agent against the new employee.
The agent successfully detected the CLEARED compliance status and proceeded directly to access provisioning without triggering the human approval gate.
I also tested the existing pending-compliance employee to confirm that the human-in-the-loop behavior remained intact.
What I Learned
The biggest takeaway was that an AI agent is more than an LLM prompt.
A useful agent combines:
• LLM reasoning
• Tool calling
• Application state
• Business rules
• Guardrails
• Human-in-the-loop decisions
• External APIs
• Testing and observability
The LLM can determine what action should happen next, but the surrounding application defines what tools exist, what data is available, what actions are permitted, and when human approval is required.
That separation becomes especially important when moving from an AI demo toward a production system.
Final Thoughts
This project gave me hands-on experience with the complete lifecycle of a small AI agent: setting up the development environment, integrating an LLM API, debugging a model compatibility issue, implementing a new workflow scenario, testing different execution paths, and submitting the work through GitHub.
More importantly, it helped me understand how LLMs, tools, workflow state, and deterministic business rules can work together to automate a real-world process while keeping humans in control of sensitive decisions.
Top comments (0)