autonomous-hr-chatbot: a LangChain agent with three tools, and a v2 that drops LangChain entirely

What the HR agent actually does, and who the README is written for

The project is a prototype enterprise application. Its stated job is to answer HR queries using the tools it has on hand, and the README calls it "mostly autonomous" in the title of the companion Medium article. The intended reader is an engineer or architect who wants to see the agent-and-tools pattern wired to something more concrete than a weather API. That is the whole scope. The employee data is a csv of dummy records (name, supervisor, number of leaves), and the timekeeping policy the agent retrieves from is described as a ChatGPT generated sample HR policy document. Nothing in the repository is a production HR system, and the README does not present it as one. The tech stack section is where the real ambition shows: SAP HCM as the source system for employee data, Azure Data Lake for landing the csv files, Azure Data Factory to build the pipeline, Azure OpenAI Service for the model. Those are named as the surrounding enterprise context, not as components the repository installs for you. If you are evaluating this to answer a question like "can an LLM answer leave-balance questions from our HRIS", the repository gives you a working shape for that answer and leaves the integration to you.

Three tools, three very different risk profiles

The agent has three tools, and they are not equivalent. The first is a retrieval tool over the timekeeping policy document: embeddings were created with OpenAI's text-embedding-ada-002 model and stored in a Pinecone index. That is a standard retrieval path and the least surprising part of the design. The second tool is employee data. A csv is loaded as a pandas dataframe and manipulated by the LLM through LangChain's PythonAstREPLTool. Read that again: the model writes Python, and that Python executes against the dataframe. The README states this plainly, without a sandbox note, a read-only wrapper, or an allowlist of operations. For dummy employee records that is a reasonable demo. For anything resembling real personnel data it is the single design decision you have to make a call on before anything else. The third tool is LangChain's calculator chain module, LLMMathChain, which handles arithmetic the model should not do in its head. So two of the three tools are low-risk and one is a code-execution surface. The repository does not try to hide this; it also does not flag it.

The v2/ directory is a different project wearing the same name

The 2026 update note at the top of the README says a modernized version using an agent loop via OpenAI's Responses API lives in v2/, with no LangChain, no Pinecone, and gpt-5.2 reasoning summaries. The original 2023 implementation is preserved below as a reference. That is a substantial change of approach, not a version bump. Removing LangChain means the agent loop, the tool dispatch and the prompt assembly are now the maintainer's own code rather than a framework's abstractions. Removing Pinecone means the policy retrieval no longer goes through an external vector database, though the README does not say what replaces it, and that is a gap worth checking in the v2/ source before you plan around it. The switch to reasoning summaries suggests the loop exposes the model's intermediate reasoning rather than hiding it. If you are choosing where to start, the README's own framing is explicit: v2/ is the modernized version, the code below it is a reference. Treating the 2023 code as the thing to adopt would be reading the repository against its author's stated intent.

Getting it running: pip, two files, one notebook

The setup is short. Install Python 3.10, clone the repository, then run `pip install -r requirements.txt`. API keys go into `hr_agent_backend_local.py`, or into `hr_agent_backend_azure.py` if you want the Azure variant, in which case you uncomment it in `frontend.py`. The front end starts with `streamlit run hr_agent_frontent.py` (the README spells the filename that way, with the typo, so copy it exactly or check the actual filename in the repo before running). The Pinecone side is a separate step. You create a Pinecone account, note the API key and environment values, then run the notebook `store_embeddings_in_pinecone.ipynb`, replacing the Pinecone and OpenAI keys with your own. Embeddings for the policy document are generated with text-embedding-ada-002 and written into a Pinecone index. The front end uses the streamlit_chat component. There is no Dockerfile, no environment variable convention and no configuration file mentioned in the material; keys live in source. That is the kind of detail that is fine for a prototype and unacceptable the moment the repository is cloned by someone other than its author.

Where this is the wrong tool

The clearest failure mode is the one the repository is best known for. PythonAstREPLTool gives the model a Python interpreter pointed at a pandas dataframe. Prompt injection through a user message, or a malformed instruction, becomes arbitrary code execution in whatever environment the Streamlit process runs in. The README offers no mitigation. If your employee data is real, that path is not a configuration you tune, it is a component you replace, for example by exposing named lookup functions that take an employee id and return a fixed set of fields. The second limitation is scope. Three tools cover timekeeping policy, employee records and arithmetic. An HR assistant in practice also faces benefits enrollment, payroll questions and policy interpretation across jurisdictions, and each of those is a new tool with its own data access question. The third is the dependency surface of the 2023 version: LangChain, Pinecone, Streamlit, OpenAI, plus Azure OpenAI and Azure Data Lake if you follow the enterprise framing. LangChain's agent and tool APIs moved quickly through 2023 and 2024, so a pinned requirements file from that period is the realistic starting point, and the v2/ rewrite exists partly because of that churn. Finally, the repository has no releases listed, so there is no versioned artifact to pin against other than the commit you clone.

What it is not: a comparison with a plain function-calling loop

The obvious alternative is to skip the agent framework and write a tool-calling loop directly against the model's function-calling API. That is essentially what v2/ does by dropping LangChain. The difference is not cosmetic. With LangChain's agents module you get the tool abstraction, the intermediate-step handling and the prompt scaffolding, and you inherit the framework's release cadence and its opinions about how tools are described. With a hand-written loop you own the dispatch table, you decide exactly what the model sees between steps, and you can log every tool call in your own format. The cost is that you rebuild the parts you would otherwise import. This repository is unusual in shipping both, which makes it useful as a comparison rather than as a recommendation: the 2023 code shows what the framework gives you, and v2/ shows what it costs to keep. If your team already runs LangChain elsewhere, the 2023 structure will look familiar. If you have been burned by framework upgrades, the v2/ approach is the one the maintainer moved to.

Maintenance, licensing and the upgrade question

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it does not carry the network-service or source-disclosure obligations of copyleft licences. It also means no warranty and no support obligation from the author. This is not legal advice; check the LICENSE file and your own counsel for anything consequential. On maintenance: the repository was last pushed in April 2026 and is not archived. The two-directory structure is itself a maintenance statement. The 2023 code is frozen as a reference, and active work happens in v2/. For a team adopting this, that means the upgrade path is not a version bump inside one codebase, it is a migration from the LangChain implementation to the Responses API loop. Budget for that as a rewrite of the agent layer, because the tool dispatch, the retrieval path and the model interface all change at once. The parts likely to survive the migration are the ones you write yourself: the policy corpus, the employee data schema, and whatever access controls you put around them. The parts likely to be discarded are the framework glue.

Editorial conclusion

Adopt this as a reference architecture, not as a deployable HR system: the employee data is dummy, the policy document is ChatGPT-generated, and the README asks you to paste API keys directly into hr_agent_backend_local.py. If you want the current design, start in v2/ and treat the 2023 code as a record of how the LangChain agent and tool pattern was assembled. Before you build on either, verify two things yourself: whether v2/ still depends on Pinecone for the policy retrieval step, and whether the PythonAstREPLTool path is something you can accept against a real employee dataframe.

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. stepanogil/autonomous-hr-chatbot on GitHub