Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback.
"Agent" got popular faster than it got defined.
Everyone is shipping one, almost nobody agrees on what the word means, and half the things called agents are really just a chatbot with extra steps.
This is part 1 of a short series where we build up a working mental model for agents, based on the patterns OpenAI published in their Practical Guide to Building Agents.
By the end of these three posts you should be able to design one without copying a tutorial line by line.
Let's start with the obvious question.
So what is an agent?
Here is the definition worth memorizing:
An agent is a system that independently completes a task on your behalf.
The key word is independently.
A normal program automates steps that you wired up in advance.
An agent runs the workflow itself, decides what to do next, notices when the job is finished, and hands control back to you if it gets stuck.
That last part is where most "agents" fall apart.
A single-turn LLM call, a sentiment classifier, a chatbot that answers one question and forgets everything: none of those are agents.
They use a model, but they don't let the model drive.
Two things separate a real agent from an LLM feature:
- It uses the model to run the workflow. The model makes decisions, recognizes when it is done, and can correct itself or stop and ask for help.
- It uses tools to act. It pulls in context and takes actions through external systems, and it picks the right tool for the current situation, inside limits you define.
Here is the loop in its simplest form:
If the model is the thing choosing which arrow to follow, you have an agent.
If you hardcoded the arrows, you have a workflow with an LLM bolted on.
Both are fine.
They are just different tools.
When you should actually build one
Agents are not free.
They are slower, harder to test, and harder to reason about than a plain script.
So the first real skill is knowing when not to build one.
Reach for an agent when traditional rule-based automation starts to crack.
Three signals show up again and again:
- Decisions need judgment. Lots of nuance, exceptions, and context-sensitive calls. Think refund approval, where the "right" answer depends on the customer's history and the specifics of the complaint.
- The rules have become a swamp. A system that grew into hundreds of brittle if-statements that nobody wants to touch. Vendor security reviews are a classic example.
- The input is messy and unstructured. Reading documents, pulling meaning out of free text, holding a real conversation. Processing a home insurance claim, for instance.
The fraud example makes the difference concrete.
A rules engine is a checklist: it flags a transaction when preset thresholds trip.
An agent behaves more like a seasoned investigator.
It weighs context, spots patterns that no single rule covers, and catches suspicious activity even when nothing technically broke a rule.
A quick gut check before you commit:
If your problem lives on the left side of that tree, write the script.
You will thank yourself later.
The three pieces every agent has
Strip away the frameworks and every agent comes down to three parts:
- Model. The brain. It does the reasoning and decision-making.
- Tools. The hands and eyes. External functions or APIs the agent calls to fetch data or take action.
- Instructions. The rulebook. Clear guidelines for how the agent should behave.
In code, that is genuinely all it is. Here is the shape of it:
weather_agent = Agent(
name="Weather agent",
instructions="You help users with questions about the weather.",
tools=[get_weather],
)
Three fields. A name, a set of instructions, a list of tools.
Everything else in agent design is just making each of those three pieces better.
Tools themselves come in three flavors, and it helps to name them:
| Type | What it does | Example |
|---|---|---|
| Data | Pulls in context the agent needs | Query a database, read a PDF, search the web |
| Action | Changes something in the world | Send an email, update a CRM record, file a ticket |
| Orchestration | Other agents, used as tools | A research agent, a writing agent |
That last row is a hint about where this series is going.
An agent can be a tool for another agent, which is how you build bigger systems without one giant prompt trying to do everything.
What's next
You now have the vocabulary: a definition, a test for when an agent is worth it, and the three parts that make one up.
In part 2 we get into orchestration.
One agent or many? When does splitting things up actually help, and when does it just add moving parts? We will cover the run loop, the manager pattern, and handoffs, with diagrams for each.
Disclaimer: This article was written by me; AI was used to fix grammar and improve readability.
AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs โ without telling you. You often find out in production.
git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.
Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.
โญ Star it on GitHub:
HexmosTech
/
git-lrc
Free, Micro AI Code Reviews That Run on Git Commit
| ๐ฉ๐ฐ Dansk | ๐ช๐ธ Espaรฑol | ๐ฎ๐ท Farsi | ๐ซ๐ฎ Suomi | ๐ฏ๐ต ๆฅๆฌ่ช | ๐ณ๐ด Norsk | ๐ต๐น Portuguรชs | ๐ท๐บ ะ ัััะบะธะน | ๐ฆ๐ฑ Shqip | ๐จ๐ณ ไธญๆ | ๐ฎ๐ณ เคนเคฟเคจเฅเคฆเฅ |
git-lrc
Free, Micro AI Code Reviews That Run on Commit
ย 
ย 
ย 
ย 
GenAI today is a race car without brakes. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.
git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.
In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen
At a glance: 10 risk categories ยท 100+ failure patterns tracked ยท every commitโฆ
Top comments (7)
Hey Maneshwar bro, this is an excellent breakdown. :D
You hit the nail on the head with "agent got popular faster than it got defined." The amount of basic chatbots wrapped in a system prompt claiming to be "autonomous agents" right now is wild. I love your distinction: if you hardcoded the arrows, itโs a workflow, not an agent. That is a great mental model for developers trying to cut through the hype.
Also, kudos for the honest disclaimer about using AI for readabilityโit actually perfectly bridges into why you built git-lrc.
Bro, the tool sounds incredibly timely. You're totally right that AI code generation is a race car without brakes. We've all seen AI write 50 lines of brilliant code while silently deleting a crucial edge case or introducing a security vulnerability. Having a lightweight, pre-commit AI reviewer to catch those slip-ups before pushing to remote is a fantastic idea, especially since it keeps the feedback loop tight and local.
Dropped a star on the repo! ๐
Thanks a lot bid <3
It's bud bro, seems like a typo ๐ ๐
Yeahhh xD
Hey!! Maneshwar hope you are doing well!! :D
I really liked the way you explained the idea of an agent. When I first started hearing terms like AI agents, MCP, workflows, and automation, everything sounded far more complicated than it needed to be. This post breaks it down into something much easier to understand and shows that an agent is less about "magic AI" and more about combining reasoning, memory, and actions to achieve a goal. It also highlights why agents are becoming such an important topic in modern software development. Great introduction for anyone curious about the space!
Thanks a lot Divyanshi <3
Some comments may only be visible to logged-in visitors. Sign in to view all comments.