In partnership with
AI is in 60% of engineering work, but only 20% can be handed off without someone babysitting the output. Join this live webinar on June 24 (free) to see how top teams are using a context engine to level up.
AI Agents Are Reading Your Docs. Are You Ready?
Last month, 48% of visitors to documentation sites across Mintlify were AI agents, not humans.
Claude Code, Cursor, and other coding agents are becoming the actual customers reading your docs. And they read everything.
This changes what good documentation means. Humans skim and forgive gaps. Agents methodically check every endpoint, read every guide, and compare you against alternatives with zero fatigue.
Your docs aren't just helping users anymore. They're your product's first interview with the machines deciding whether to recommend you.
That means: clear schema markup so agents can parse your content, real benchmarks instead of marketing fluff, open endpoints agents can actually test, and honest comparisons that emphasize strengths without hype.
Mintlify powers documentation for over 20,000 companies, reaching 100M+ people every year. We just raised a $45M Series B led by @a16z and @SalesforceVC to build the knowledge layer for the agent era.
Welcome to Grind Engineer, your guide to becoming a better software engineer! No fluff. Pure engineering insights.
Added Job Opening in the end of the article!
90% of what the industry calls "AI agents" in 2026 are just chatbots with a tool call. A user asks a question, the model calls a function, and the result gets pasted back into the response. That is not an agent. That is an API wrapper with a language model on top.
An actual agent perceives its environment, reasons about what to do, takes action, observes the result, and loops until the task is done. No human in the middle approving every step. The difference matters because the architecture is completely different.
Chatbot vs Agent: The Line Most Engineers Miss
The difference is not "smart" vs "dumb." It is reactive vs autonomous.
A chatbot waits for input, generates a response, and stops. One turn. Done. Even if it calls a tool mid response, the user drives every step of the interaction.
An agent receives a goal, breaks it into subtasks, executes them in a loop, adapts when things go wrong, and only stops when the goal is met or it hits a defined limit.
Property | Chatbot | Agent |
|---|---|---|
Who drives the loop | The user | The agent itself |
Number of steps | 1 (single response) | Many (until goal is met) |
Tool usage | Optional, single call | Required, multiple calls |
Memory across steps | Context window only | Context + external memory |
Error handling | Returns the error | Retries, adapts, or escalates |
Stopping condition | User stops asking | Goal achieved or max steps hit |
💡 Key Insight: If the human has to tell it what to do at every step, it is a chatbot. If it figures out the next step on its own, it is an agent. The distinction is autonomy, not intelligence.
The Perceive Act Loop
Every agent, from a Roomba to Claude Code, runs the same fundamental loop. It comes from Russell and Norvig's AI textbook (1995) and has not changed in 30 years.
Perceive: The agent reads its environment. For a coding agent, that means reading the codebase, error logs, test output. For a customer service agent, that means reading the ticket, user history, knowledge base.
Reason: The agent thinks about what it knows and what it needs. This is where the LLM does its work. "The test failed because of a null pointer. I should check where that variable gets initialized."
Act: The agent calls a tool. Runs a command. Edits a file. Makes an API request. Something changes in the world.
Observe: The agent reads the result of its action. Did the test pass now? Did the API return an error? What changed?
Then it loops back to Perceive. This continues until the agent decides the goal is complete or it runs out of steps.
while not done and steps < max_steps:
state = perceive(environment)
plan = reason(state, goal, memory)
result = act(plan, tools)
done = evaluate(result, goal)
memory.update(state, plan, result)
steps += 1
That is the entire agent architecture in 7 lines. Everything else, every framework, every SDK, is infrastructure around this loop.
Tools and Memory: What Makes the Loop Useful
The loop alone is not enough. An agent without tools is just a model talking to itself. An agent without memory forgets what it did three steps ago.
Tools are functions the agent can call. Search the web. Read a file. Run a SQL query. Call an API. Every major agent framework in 2026, LangGraph, OpenAI Agents SDK, Pydantic AI, represents tools as structured function definitions that the model can invoke by name.
Memory is how the agent tracks state across loop iterations. Short term memory lives in the context window (the conversation so far). Long term memory lives in external stores like vector databases. Without memory, the agent would re read the entire codebase on every loop iteration.
Component | What it provides | Without it |
|---|---|---|
Tools | Ability to change the world (read, write, search, execute) | Agent can only talk, never act |
Short term memory | Context from earlier steps in this session | Agent forgets what it just did |
Long term memory | Knowledge from past sessions and external data | Agent starts from zero every time |
Reasoning | Planning, deciding what to do next | Agent calls tools randomly |
The model is the brain. Tools are the hands. Memory is the notebook. You need all three.
The Four Agent Types Engineers Should Know
Russell and Norvig defined four agent types in their AI textbook. These categories still hold in 2026 because they describe fundamentally different architectures, not just different prompts.
Simple Reflex Agent. Maps the current input directly to an action. No memory, no planning. "If the user says 'hi', respond with 'hello'." Most rule based chatbots are reflex agents. Fast but brittle. They break on anything unexpected.
Goal Based Agent. Has an internal model of the world and a goal. Plans a sequence of actions to reach the goal. Most production AI agents today are goal based. "Deploy the feature to staging, run the tests, fix any failures, then merge."
Utility Based Agent. Like a goal based agent but with a scoring function. Instead of "reach the goal," it optimizes for "reach the best outcome." Used when there are multiple valid paths and the agent needs to pick the best one. "Find the cheapest flight that arrives before 6pm with at most one layover."
Learning Agent. Updates its own decision rules over time. Learns from feedback on past actions. Rare in LLM agents today because fine tuning on every interaction is expensive. Most systems approximate this with RAG (retrieving past experiences) rather than actual weight updates.
Agent Type | Memory | Planning | Learning | Production Example |
|---|---|---|---|---|
Simple Reflex | None | None | None | Rule based chatbots, auto responders |
Goal Based | Yes | Yes | No | Claude Code, Devin, coding agents |
Utility Based | Yes | Yes (with scoring) | No | Travel booking agents, pricing optimizers |
Learning | Yes | Yes | Yes | Recommendation systems with feedback loops |
Most agents you will build are goal based. That is the sweet spot: smart enough to plan, simple enough to debug.
Where Agents Are Running in Production Today
Agents are not theoretical anymore. Gartner estimates that 40% of enterprise applications will integrate AI agents by end of 2026, up from under 5% in 2025.
Coding agents are the most mature category. Claude Code, Cursor, Devin, and GitHub Copilot all run the perceive act loop: read code, reason about changes, edit files, run tests, observe results, repeat.
Customer support agents handle ticket triage, knowledge retrieval, and response drafting. TELUS deployed agentic AI across operations and saved 40 minutes per interaction across their workforce.
Data analysis agents translate natural language to SQL, run queries, interpret results, and generate reports. Suzano built an agent that achieved a 95% reduction in query time for supply chain data.
DevOps agents monitor production systems, detect anomalies, correlate signals across logs and metrics, and execute runbooks. These are still mostly goal based agents with human approval gates on destructive actions.
The common thread: every production agent is a loop. Perceive the environment, reason about the next step, act with a tool, observe the result. The toolset changes. The loop does not.
What This Means For Engineers
1. Before you reach for an agent framework, understand the loop. If you can write the while not done loop with perceive, reason, act, and observe, you understand agents. Everything else is optimization and infrastructure.
2. Most tasks do not need agents. If the workflow is fixed (always do A then B then C), use a pipeline. Agents shine when the next step depends on the result of the previous step and you cannot predict the path upfront.
3. Start goal based. Reflex agents are too simple for real work. Utility based agents add complexity you probably do not need yet. Learning agents require infrastructure for feedback and retraining. Goal based agents hit the sweet spot for 90% of use cases.
Job Openings
Software Engineer, New Grad @Stripe: Apply Here
Software Engineer, Payments and Risk @Stripe: Apply Here
Software Engineer, Data & AI @Stripe: Apply Here
Software Engineer (1+ YOE) @Stripe: Apply Here
Software Engineer 2, iOS @Uber: Apply Here
See you in the next one!
Scortier, Signing Off!