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:

1. 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.
2. 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:

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…

View on GitHub