parallel tool calls are not only about reducing latency, you also need to think about concurrency.

an ai agent can request multiple tool calls in a single response.

say your agent needs to:

- fetch a customer's profile
- get their recent orders
- check their payment history

these operations are independent, so you can execute them in parallel and reduce the overall response time.

but what if the agent needs to update the customer's account and then fetch the updated details?

here you can't run both in parallel because the second operation depends on the first one. otherwise you might end up fetching stale data.

so before executing parallel tool calls, you need to think about:

• are these operations independent
• are they modifying the same resource
• does the execution order matter
• what happens if one of the calls fails
• are there any limits on concurrent requests

also make sure you map every tool result back to its original tool call id.

parallel execution helps reduce latency, but you need to handle dependencies and side effects properly.

you can learn everything, build anything and deliver great work.

but it all comes down to getting clients.

if nobody is paying for your website, product or service, you're making zero money from it.

and getting clients is the hard part.

transactions guarantee atomicity, but they don't prevent race conditions.

you need locks and isolation level to handle that.

you don't need to make a LLM call in every step

when building an agent, it's tempting to let the model make every decision.

but not every operation requires reasoning.

for example:

- validating tool arguments

- checking permissions

- handling retries

- saving execution state

- executing predictable operations

- handling known errors

these can be handled by application code properly.

you should use the LLM when you actually need reasoning or a decision based on context.

its always better to use deterministic code when the expected behavior is already known.

this makes the system easier to test, debug and maintain. it also avoids unnecessary model calls, latency and cost.

adding more consumers do not always increase kafka throughput.

partitions are the unit of parallelism in kafka.

if a topic has 3 partitions and your consumer group has 5 consumers, only 3 can actively consume. the other 2 stay idle.

so before scaling consumers, check your partition count and consumer lag.

when building an agent loop, you need to keep track of what the model has done so far.

especially when the model can call multiple tools, query databases, search repositories or fetch external information.

otherwise, it might repeat previous operations or make decisions without considering the results of earlier actions.

a good way to handle this is to use a state driven approach.

here's how it works:

1. start a task and initialize its state.

2. ask the model for the next action. provide the task, relevant state and available tool schemas.

3. validate the model's response.

4. if it requests a tool, execute it and record the result as an observation.

5. send the updated state and observations back to the model so it can decide what to do next.

6. stop when the model returns a final answer or the application reaches a predefined limit.

models don't retain what you talk about, your AI application is responsible for giving them memory.

what is an agent loop?

an agent loop is a process where an LLM performs multiple steps to complete user's request.

at each iteration, the model looks at the current context, uses the results of previous actions and decides what to do next.

if it needs more information, it can call tools, use their results and continue working on the task.

this process continues untill the model completes the task or reaches a stopping condition.

models can generate answers based on the context you provide and what they learned during training.

but they don't remember what you said in previous requests.

so if you want an AI application to remember previous conversations, you need to provide that context to the model.

the simplest way to do this is to send the conversation history along with the current query.

let's take an example.

you say: today the weather is stormy in the thar desert.

model says: okay.

now you ask: how is the weather in the thar desert?

if you don't send the previous conversation, the model won't know that you already told it about the weather.

but if you send the conversation history along with the new query, the model can use that information to answer.

this is the simplest way to understand how memory can work in ai agents.

as conversations grow longer, you may need to summarize the history or store important information separately instead of sending everything every time.

amazon q integration with aws is great. you can ask it to do many trivial things right there without having to switch tabs or google how to do them.

you must be able to answer questions about your previous experience.

it's a big red flag if you don't know something you actually worked on during an interview.

models are trained up to a cutoff date. so they do not have information about events or data introduced after that.

to handle this, we have ways to provide additional context to the model for a particular query.

this doesn't increase its actual knowledge or change what it was trained on.

your application provides additional context that helps the model generate answers for specific queries.

that context can come from:
- application tools
- mcp tools
- rag systems

when a query requires external information, the model can decide which available tools to call based on the query.

the tool retrieves the relevant information, which is then provided to the model as context to generate the final answer.

when you are automating the deletion of stale infra in aws after 1 month or any given period, make sure the job first notifies the owners at least 7 days before deletion and sends a final reminder.

this helps them take the necessary actions if they don't want the infra to be deleted.

this happened with us recently, where a stale load balancer was deleted and now we are creating it again and integrating it with the service.

MCP tools are of great use when building ai agents.

LLMs decide which tool to use based on the user's request, but you shouldn't execute whatever tool call it gives you.

the tool might not be something your application allows, or it might perform an action that you don't want the LLM to trigger.

so everytime the LLM asks you to use an MCP tool, you need to validate that tool call in your application.

check if the tool is allowed, if the arguments are valid and if the action is something your application has approved.

the LLM can decide what tool it want to use, but your application should still control which tool calls actually get executed.

that's basic practice when building reliable ai applications.

when building ai agents, some tasks require multiple operations like searching, reasoning and validating previous information.

in that case, you create a loop where the LLM keeps interacting with the application until it has enough information to produce the final answer.

but here's the problem.

you need to maintain the state of the current task like

- what has been done so far
- observations that have been made
- whats still left
etc.

if you don't maintain this state, the model will repeat previous operations, lose track of what has already been done or make decisions without considering previous findings.

so in every iteration, you maintain the task state and send the relevant context back to the model.

this allows the model to continue from where it left off instead of treating every iteration as an independent query.

the loop continues until the model has enough information to produce the final answer.

as soon as you wake up, do 2 hours of focussed work with your coffee.

it just straightforward, effective and easy to follow.

you can get many things done, which you feel imp.

mcp servers help LLMs get additional information and generate better answers.

but for that, the model needs to decide which tool to call for a given query.

recently, i faced an issue where the model wasn't able to make the right tool calls because there were too many tools with overlapping use cases.

it kept making wrong calls, which led to wrong answers.

after looking into it, i added clear instructions on when to use which tool and started providing only the tools needed instead of everything an mcp server returns.

this helped the model to choose the right tools.

turning down people asking you for money is quite hard.

a relative asked me for money for the first time. i gave it to him, then had to bug him 7 or 8 times just to get it back.

then he came asking for money again. i refused, but he insisted he'd return it in 2 days.

it's been a year since then.

now i don't pick up his calls. if i ever run into him in person, i'm going to tell him the reason to his face.

he only ever called when he needed money.

you use embedding models to convert text into vectors.

to store these vectors for fast retrieval, you can use chroma db or postgres with the pgvector extension.

when a user asks a question, you convert the query into a vector using the same embedding model and compare it against the stored vectors to find the closest matches.

these matches can then be used as relevant context for the LLM before it generates a response.

that's the basic idea behind retrieval augmented generation (RAG)

at a high level, building an ai agent comes down to a few things.

- you need a model that can understand user queries and generate responses.

- use tools to let the model access external data and perform actions.

- give clear instructions on how the agent should behave and when to use tools.

- create a loop to handle multiple conversation turns and tool calls.

- store conversation history and pass relevant messages to the model so it has the context.

- use mcp when you want a way to connect your application to external tools and context sources.

- build a rag pipeline if you want the model to retrieve relevant information from your own data.

that's the high level overview of building an ai agent.

each of these points can go much deeper, but this is a good starting point.