I know I promised we’d dive straight into Agentic AI in this post — and we will. But first, let’s ground ourselves with a practical example most enterprise teams will recognise. Imagine you’ve been tasked with building a Python backend service that monitors a shared email inbox and replies to incoming messages in a way that mostly satisfies the sender. Just a back end solution without a fancy pants user interface.

Traditional Automation – The Classic Approach Here’s the basic pseudo-architecture we’d need:

1. A function that fetches a list of unread email IDs from the inbox.
2. A second function that takes an email ID and returns the full email text (plus any reply-chain context).
3. A logic block (the heart of the program) built with if/else statements and database lookups. For example: • If the email contains “purchased”, flag it as an existing customer. • If it contains “would like to buy”, treat it as a sales opportunity. • Cross-check the sender’s email address against your customer database. • Scan the reply chain for previous context. These checks populate variables such as is_existing, is_new, is_complaint, requested_product, etc. Once the logic finishes, the program decides the next action: send a standard product list, reply with specific information, or escalate the email to a human agent. This kind of system is entirely possible to build today with straightforward Python code. The logic can grow complex, but it remains fully deterministic and under your control.

Enter the Agentic Harness Now suppose you want to avoid writing and maintaining that ever-growing list of if/else statements. This is where an agentic system comes in. You still need the same helper functions (reading emails, sending replies, looking up products, escalating tickets). In agentic frameworks these are simply renamed Tools. What changes is the middle part. Instead of hard-coded logic, you introduce a Harness — a lightweight orchestrator that sits between the email listener and your tools. A typical agentic flow looks like this:

• An email arrives and triggers the harness.
• The harness calls tools to fetch the email text and any relevant context.
• It packages that information together with a system prompt (sometimes called a “Skill”; essentially a plain-text file that describes the agent’s role, lists the available tools, and specifies the exact output format the LLM must follow).
• The harness sends everything to an LLM via its API.
• The LLM; which, as we’ve covered throughout this series, is still just a sophisticated next-token predictor which generates the most likely continuation of the input text.
• The harness inspects the LLM’s response. If it’s not in the required structured format (e.g., it fails to call a tool correctly), the harness can loop back and ask the model to “try again.”
• When the response correctly names one of the available tools (e.g., “send_product_info” for product X), the harness executes that tool in the real world by sending the email reply, escalating the ticket, or updating a record. In short: you’ve replaced the complex logic block with an LLM, while keeping the surrounding functions (now called tools) exactly the same.

The Fundamental Disconnect The LLM is not “thinking” or “considering” the customer’s request. It is simply predicting which tokens are most likely to come next, based on everything it saw during training. The harness, however, treats the LLM’s output as a reasoned answer or decision.

This creates a subtle but critical mismatch:

• The LLM believes it is finishing a piece of text.
• The harness believes it is consulting an expert.

That’s why every robust agentic implementation includes retry logic, output validation, and hallucination guards. The very need for these safeguards reveals the true nature of the system: we are asking a token-prediction machine to simulate expert behaviour, then letting its simulation trigger real-world actions. I don’t think agentic AI is inherently bad. I run a small three-agent setup at home (two connected to external LLM APIs, one local open-source model acting as orchestrator). These systems can be genuinely useful. My bigger concern is long-term sustainability. As open-source models continue to improve and API providers face growing infrastructure costs, relying heavily on paid LLM calls for every decision may become expensive. That’s why I’ve started exploring lighter-weight alternatives that still leverage the same core technologies we’ve discussed in this series.

Better Ways to Use the Underlying Technology We don’t always need to throw every problem at a full LLM or a complex agentic harness. The same innovations that power transformers — embeddings, vector spaces, and attention mechanisms — can be used more efficiently. For example, in my day job I’ve built systems that turn thousands of change records into vectors, then use simple vector similarity (plus attention-style weighting) to match context across different fields, all without calling an LLM at runtime. These approaches give us ranking, semantic search, and contextual comparison at a fraction of the cost and latency. We’ll explore exactly how that works in the next post.