Every time you connect an AI tool to a company system, it is a custom job. Connect an AI model that reads and writes text (language model) to Salesforce, and you write custom code. Connect it to Jira, and you write different custom code. Connect it to an in-house database, and you write a third kind. Now multiply that by every model, every tool and every team. The work grows much faster than the number of parts. Each new model or tool does not add one job. It adds a job for every model or tool already there.

MCP, a shared standard, fixes the first half of that problem. It sets one way for AI models to talk to outside tools. But a standard for how systems talk (protocol) is only a set of rules. Someone still has to build the front door, check who is calling, limit how often they call, and make the whole thing safe for a large company. This post explains how, using Nexus, a gateway for MCP I am designing (not built yet, October 2026).

What does a gateway change?

Without a gateway, every agent talks to every tool directly. Passwords and keys are spread across many codebases. Each connection handles errors in its own way. And nobody has one place to see or limit what the agents are doing.

A gateway sits between any AI model and any company tool. One gateway, one standard, and no custom code per tool. Agents speak MCP to the gateway. The gateway deals with the messy details of each system behind it (backend). The key gain is that security and control now live in one place.

The building blocks

The core gateway

Nexus, my planned gateway (not built yet, October 2026, so this post describes the design, not results), is a small web server built with a Python web framework (FastAPI), that will follow the MCP rules. It will take tool requests from any app that speaks MCP. It will send each one to the right system and return a tidy answer. It will also check that each request is well formed before passing it on.

I chose FastAPI for three reasons. It handles many requests at once without waiting on each one (async). It writes a machine-readable description of every request it accepts (OpenAPI) for free. And MCP tool definitions fit neatly into its data-checking library (Pydantic). Each request also carries its login details cleanly through a built-in way of handing shared pieces to each request (dependency injection).

Logins the model never sees

Company tools need login details: keys for program access (API keys, OAuth tokens), or shared service accounts. The rule that matters most is simple. The AI model should never see them. If a key shows up in the text sent to the model (prompt) or in a tool result, it can leak into logs, chat records or an attacker’s output.

Nexus will add the login details at the last moment. The model asks for a tool, and only then, just before the call goes out, Nexus attaches the key. The keys are stored encrypted in a database (PostgreSQL), and they can be rotated on a schedule. From the model’s side, it asks for an action and gets a result. It never touches a secret.

Limits that protect your systems

Agents can be over-eager. A loop or a badly behaved session can hit a system with thousands of calls. Nexus will cap how many calls each session may make in a given time (rate limiting), so no single session can swamp the systems behind it.

Those caps are kept in a fast shared memory store (Redis), not inside each copy of the gateway. That matters at scale. When several copies of Nexus run behind a traffic splitter (load balancer), the caps must be shared across all of them. A counter kept inside each copy would let a busy session dodge its cap by spreading calls across copies.

Saved answers that save money and time

Many agents ask the same question at the same moment. If ten agents ask for the same Jira ticket within thirty seconds, only one request should reach Jira. Nexus will keep a short-lived copy of recent answers (cache). That cuts repeat calls, shortens the wait for an answer (latency) and keeps you inside your usage limits.

A tool list that makes new tools cheap

New tools are added by writing a short settings file in a simple text format (YAML). You write the tool’s name, what it does, the shape of the data it accepts (schema), how it logs in, and the web address it calls (endpoint). Nexus then builds the MCP tool definition for you. Adding a new company tool takes minutes, not days. That is the whole point of the design: the cost of the next connection stops growing.

Deployment: run where your data lives

Companies run in the cloud, on their own servers, or a mix of both. So the gateway has to run anywhere. It ships as a sealed, ready-to-run package (Docker container). Each tool connection can run as its own small helper package next to the gateway (sidecar), with its own parts. That way, a problem in one connection cannot break another.

Security questions to ask of any gateway

Whether you build one or buy one, ask these:

• Where do keys live, and can the model ever see them?
• Is there a cap per session, and is it shared across every copy?
• Can I add or remove a tool without restarting everything?
• Can I see every call each agent made, and who made it? The last one is why the ability to see what a live system is doing (observability) matters. A gateway sees every tool call, so it is a natural place to feed a monitoring system like the one in monitoring and evaluating production AI.

What should you measure?

When Nexus is built, the numbers to watch are: how many tools it connects, the typical (median) response time, how long a new tool takes to add, and how many sessions it holds at once. The one I care about most is how fast a new tool goes in. It shows whether the design really stopped the cost from growing.

When you do not need a gateway

If you have one model and one or two tools, a direct connection is simpler. A gateway would add moving parts you do not need. The case for a gateway grows with the number of models, tools and teams. It also grows with how much you care about keys, limits and seeing what happens.

The short version

Use MCP as the standard, and put one gateway between your models and your tools. Keep keys out of the model’s sight. Share call limits across every copy. Save repeat answers. And add new tools through a settings file instead of new code. The next connection becomes a short file, not a project.

The full design is in the Nexus case study. If you are connecting agents to company tools and want to do it safely, book a call.

Inbound leads go cold while they wait. Someone fills in your form, opens a chat or sends an email. Then they wait. By the time your team reads the message, decides if it is worth a call and writes back, the buyer has often talked to someone else. A slow first reply lowers your chance of ever winning that lead. That is the problem, and it is why so many teams put an AI model in front of their inbox.

Most teams make the same mistake. They hand every message to a model, ask it to “qualify the lead”, and hope. When the model gets it wrong, nobody can see why. When the message is junk, they still pay for a model call to find that out. This post shows a better way to qualify leads with AI. I used it to build CAT-01, the Instant Lead Agent.

What are you actually deciding?

Qualification sounds like one decision. It is really three:

1. Is this a real, readable enquiry? An empty form, a garbled paste or an obvious bot is not a lead. You do not need judgment here. You need a check.
2. How good is the lead? This is where AI earns its keep. “We need this live by next month. We have approved the budget.” means something very different from “just curious what you do”, even when both come through the same form.
3. What should happen next? A strong lead might get a booked call right away. A weak one might get a polite reply and nothing more. Someone has to decide, and they should decide the same way every time.

If you put all three into one big instruction to the model (prompt), you cannot check its answer. If you split them, each step uses the right tool: plain rules for the first, a model for the second and a routing table for the third.

Step one: a deterministic gate

Each channel sends messages in its own shape: a web form looks different from a chat widget or an email. Before the model sees anything, turn every message into one standard shape (normalise). That shape holds who sent it, how to reach them, what they said and where it came from.

This clean-up step also works as a gate. It follows fixed rules and always gives the same answer for the same input (deterministic). If a message is broken, the gate stops it before it reaches the model and sets it aside for a person to check. You spend nothing on a model call to learn that the message was broken.

This helps in two ways. First, your costs stay predictable, because you only pay the model to judge messages that deserve it. Second, you can tell your failures apart. “The message was broken” and “the model was unsure” are different problems, and you want to see which one happened.

Keep the gate boring. You should be able to read its code in a minute, not take it on trust.

Step two: a model that shows its reasoning

Every message that passes the gate goes to a live AI model, which reads the lead’s own words. A bare score is not enough. The model should give you three things:

• A tier: hot, warm or spam.
• A budget score, so you can see how the model read the money signals in the message.
• Its reason, in plain English.

Most teams skip the reason, yet the reason is what makes the system usable. Say the model marks a lead warm and your salesperson disagrees. The reason shows exactly what the model read into the message. Maybe it fixed on one phrase. Maybe it missed a deadline the lead mentioned in passing. Either way, you now argue about evidence instead of shrugging at a black box.

The same model call also drafts a personal first reply. This is where the speed comes from. Your team no longer starts from a blank page. They already have a draft that mentions what the person asked about. They can send it as it is, tweak it or throw it away. Either way, the first reply goes out in minutes, not hours.

Step three: let the tier decide the next move

Once the model sets a tier, the next step should follow on its own. In CAT-01 a hot lead can become a record in your sales contact system (CRM), a held booking slot, a WhatsApp or email follow-up and an alert to your team. A lead that is not a fit gets a polite reply instead of silence. That protects your reputation better than ignoring them, and it costs less than a long back-and-forth.

Look at what this does to your team’s job. Nobody sorts the inbox by urgency (triage) any more. They look at a short list the system has already sorted. Each lead comes with a reason and a reply ready to go. Your people spend their time on the leads that need a person.

Keep a human in the loop where it counts

Automation does not mean removing people. Match the amount of freedom you give the system to the cost of a mistake:

• Drafting a reply costs little if it goes wrong, because a person reads it before it goes out. Automate it.
• Alerting your team costs little too. Automate it.
• Sending a message to a stranger under your name, with no review costs a lot if it goes wrong. Start with a draft. Remove the review only after you have watched the system get it right for a while.

I apply the same rule to my own contact form. My plan: the agent labels each message and drafts a reply for me to review. It never replies to the visitor by itself.

Why I built it on n8n

I built the whole CAT-01 agent in a visual workflow tool (n8n) that shows each step, so you can open it and read it. I chose it for ownership. The workflow ships as a bundle that runs on the client’s own server, so the client owns the data and the logic. Changing a routing rule does not need a developer. If your qualification logic lives inside a vendor’s black box, every change becomes a support ticket. If it lives in a workflow you can read, your sales manager can change it.

What should you measure?

If you build something like this, track three numbers from day one:

• Time to first reply. The whole system exists to shrink this number.
• How often a person overrides the tier. If people override it often, the model’s reasoning is off, and its written reasons show you where.
• How many messages the gate sets aside. A sudden jump usually means a form or connection upstream has broken, long before anyone complains.

The short version

Split the decisions. A deterministic gate catches broken input. A model that explains itself judges quality. A routing step turns the verdict into action. Keep a person in charge wherever a mistake costs a lot. Do that, and every new lead gets a thoughtful reply in seconds instead of going cold in your inbox.

Want to see it work on your own lead messages? The CAT-01 case study explains how to request a private demo link. If you are working on a similar problem, book a call and we can talk it through.

AI systems get worse quietly. A model that was right 95% of the time last month might be right 78% of the time today, and nobody notices until customers complain. Most teams watch their servers: how busy the processor is (CPU), how much memory is used, and whether the site is up. They do not watch how the AI behaves. Are the answers still good? How often does it make things up? Is it finding the right documents? A server can be perfectly healthy while the answers it gives slowly get worse.

What is missing is a clear view of what the live system is doing (observability). Not for the servers, but for the AI itself. The question it must answer is simple: is the system still giving good answers? This post shows how to build that view, based on Sentinel, the monitoring platform I am designing for chains of AI steps (pipelines). Sentinel is planned, not built yet (October 2026), so this post describes the design, not results.

Why does ordinary monitoring miss it?

Normal monitoring answers two questions: is it up, and is it fast? Both can be true while quality falls apart. Here are a few ways that happens:

• A data source changes shape. The step that looks up documents to answer from (retrieval) starts returning weaker matches for one topic. Answers get vaguer, but no error is ever raised.
• A model or its instructions change. Behaviour shifts in small ways that pass a quick manual check.
• The questions change. Users start asking things the system was never tuned for. Quality drops on exactly the traffic that is growing.

None of these sets off an uptime alarm. You find out from a customer, which is the most costly way to find out.

Three layers of monitoring

Sentinel is designed to plug into any system built on a large AI text model (LLM) with a few lines of tracking code. It will give you three layers.

Layer one: record every step

Every model call, every tool the agent uses and every choice it makes is saved as a step-by-step record, using an open-source tracing tool (LangFuse). Each record holds the full question and answer, how long the answer took (latency), how many word pieces it used (tokens), and any labels you add. Without these records you cannot investigate anything, because you cannot see what the system actually did.

Two things matter here. First, coverage. If some calls are not recorded, the blind spots are exactly where problems hide, so Sentinel aims to record everything. Second, cost. Tracking that slows the system down gets switched off. So Sentinel’s tracking has to add so little time per call that nobody has a reason to turn it off.

Layer two: score the answers

Records tell you what happened. Scoring tells you whether it was good. Automatic checkers run on a sample of the records. They check four things: is the answer backed by the sources, is it on topic, did it follow the instructions, and is it in the right format?

Each check returns a score in a fixed format. This is where a data-checking library (Pydantic) earns its place. When a checker rates an answer, I need a proper score, not a sentence that might say “7/10”, “seven out of ten” or “pretty good”. Forcing a fixed shape on the output (schema) means scores can be averaged, tracked over time and compared day to day.

Checking a sample is a deliberate choice. Scoring every record with a model is expensive. A sample gives a reliable picture of quality at a fraction of the cost. And when something looks off, you can check more.

Layer three: alerts and dashboards

When a quality score crosses a limit you set, an alert goes out. The key is being specific. “Something is wrong” does not tell anyone what to do. A useful alert looks like this: for finance questions, the share of relevant documents found dropped below 85% over the last four hours. That tells you where to look and roughly when it started.

The dashboards are fed by web addresses the server answers (endpoints) built with a Python web framework (FastAPI). They update live over a connection that stays open (WebSocket), so you watch quality move as it happens instead of reading yesterday’s report.

Where the data lives is a design choice

Many large companies cannot send these records to an outside online service (SaaS). The records hold full questions and answers, which may include customer details or private business data. That is why I chose LangFuse for this project. It is open source and can run on the client’s own servers, so they keep full control of the data.

The records are stored in a database (PostgreSQL), because the data is naturally linked. Steps belong to records, records belong to sessions, and sessions belong to users. That database handles those links well. It also has flexible columns for extra labels (JSONB) and fast lookups by time.

Check for made-up answers on their own

An answer that sounds right but is not supported by the source, a hallucination, deserves its own score. The way to catch it is to compare the answer with the documents the system actually found. If a claim is not backed by those documents, flag it.

You can also put a check in the live path, not just in monitoring. In the design for Athena, a planned system, a checking agent reviews every answer against the source data before the user sees it. Sentinel would then watch how often that checker rejects answers, and why. A rising rejection rate is an early warning that something earlier in the chain has changed. The post on multi-agent systems for business intelligence explains that design in more depth.

Where should you start?

You do not need to build everything at once. In order of value:

1. Record everything. Start saving a step-by-step record of every call. You cannot score what you did not record.
2. Pick two or three quality questions that fit your product, such as “is the answer backed by the documents found?”. Score a sample of records against them.
3. Set one alert per quality score, for one topic or feature. A single overall average can hide a local problem.
4. Review the failures every week. The worst-scored records show you what to fix next.

Mistakes to avoid

• Alerting on averages only. A healthy overall average can hide one broken topic.
• Scores written as sentences. If checkers return prose, you cannot track them.
• Heavy tracking code. If it makes answers noticeably slower, someone will remove it.
• Sending private records to a service you do not control when your data rules forbid it.

The short version

Watch the quality of the answers, not just the health of the servers. Record every call cheaply. Score a sample with checkers that return fixed-format scores. And alert on specific drops, with the topic and the time window attached. Do this, and quiet decline stops being quiet.

The full design, including the reasons behind each tool, is in the Sentinel case study. If your AI system is already live and you are not sure how it is really doing, book a call.

Getting answers from company data is broken for most businesses. Self-serve reporting tools for business data (BI tools) promised to open data up to everyone. Instead they brought more complexity: dashboards that only their makers understand, database questions (SQL queries) that take days to write, and findings that arrive too late to act on.

The obvious fix is to put a chatbot on top of the data, so anyone can ask questions in plain English. Teams try it, and it fails in a predictable way. The chatbot answers with confidence, the answer sounds right, and some of the numbers are made up. With business data, a confident wrong number is worse than no answer, because someone makes a decision with it.

This post explains why a team of AI agents fixes this, using a system I am designing as the example: Athena. Athena is planned, not built yet (October 2026), so this post describes the design, not results.

Why is one model the wrong shape?

A single model asked a business question has to do four jobs at once. It has to work out what is being asked, find the right data, think it through, and check its own work. Models are bad at the last one. Asking a model to grade its own answer while it writes it mostly produces agreement.

The fix is to split the jobs and give each one to a part that does only that. That is what “multi-agent” really means in business. It is not about having many models for the sake of it. It is about splitting duties, the same reason a finance team has one person who prepares the numbers and a different person who reviews them.

The four roles

Athena will have four agents working together, each with its own role. They are wired up with a tool for building agent flows as a map of steps (LangGraph).

The Router sorts each question by what it is after, how hard it is, and which data it needs. A simple lookup goes down a fast path. A hard question goes through the full chain of steps (pipeline). This one choice is meant to make routine questions faster, because most questions do not need the heavy machinery.

The Retriever finds the right data, from both tidy tables and loose documents. It runs two kinds of search at once. One is search by meaning, using a database of number-based fingerprints for text (vector search in Qdrant). The other is exact keyword search, using a classic word-scoring method (BM25). Each covers the other’s blind spot. Search by meaning understands loose, everyday wording but can miss exact matches. Imagine a user asking for “Q3 2024 revenue for product SKU-4421”. A search that only looks at meaning (semantic search) might return similar products. Keyword search catches the exact product code (SKU). The two result lists are then merged by rank.

The Analyst takes the data found and turns it into insight, using a large OpenAI model (GPT-4o). This is not just a summary. The agent looks for trends, flags anything unusual and makes comparisons. Every claim is tied to specific data points, with sources.

The Validator checks the Analyst’s work against the source data. It checks the numbers, flags claims that are not backed up, and gives each answer a confidence score. This agent is the reason the answers can be trusted. It catches answers that sound right but are not supported by the data (hallucinations) before users see them.

Because the Validator is a separate step with a separate job, it can be strict in a way that a model checking itself never is.

Why a fixed map beats a free-for-all

A common pitch in this space is a crowd of agents that work out among themselves who does what. I chose LangGraph over other agent tools, such as two popular team-of-agents frameworks (CrewAI, AutoGen), for one main reason: it keeps clear track of where the work is up to.

LangGraph lets you draw the flow as a fixed map of steps. Each step passes along data in a known shape, branches follow clear rules, and progress is saved as it goes. When the Analyst fails, you want a retry rule that does the same thing every time (deterministic), not an agent deciding for itself what to try next. Live systems need failures you can predict. When something breaks at three in the morning, you want to say exactly which step failed and what the system did about it.

The trade-off is that you design the flow up front instead of letting agents make it up. For business questions that is the right trade, because the flow is mostly known: understand, find, analyse, check.

Two kinds of search are not optional

Teams new to finding documents for an AI to answer from (retrieval) often start with search by meaning alone, because it demos well. It handles vague questions beautifully. Then someone asks about a specific product code, date or account number, and it returns something similar instead of the thing they asked for.

Business data is full of exact codes and numbers. Any system that answers questions about it needs both kinds of search. That is why the Retriever uses both Qdrant and BM25 instead of picking one.

You cannot fix what you cannot see

A team of agents has more places to go wrong than a single model call. So a clear view of what the live system is doing (observability) is part of the design, not an extra. Every step in Athena will be recorded from start to finish with a tracing tool (LangSmith), showing, per agent and per question: how many word pieces it used (tokens), how relevant the data found was, how often the Validator rejected an answer and why, and how long each step took (latency).

That is more than logging. It is a structured view that feeds back into improving the system. When search quality drops for one area of data, I know within hours, not weeks. If you want to build that layer on its own, the companion post on monitoring and evaluating production AI covers it.

What to measure

When Athena is built, three numbers will matter: how often the data found is relevant, how many made-up answers the checker catches, and how long a typical answer takes. The most telling is the second. Catching nearly all made-up answers is what makes the rest usable, because analysts will only rely on a system that rarely lies to them.

When do you not need this?

A team of agents means more moving parts to build and run. If your questions are narrow, your data is small and a mistake is cheap, one well-instructed model may be enough. The case for several agents grows as three things grow: the variety of questions, the size and mess of the data, and the cost of a wrong answer.

The short version

Do not ask one model to understand, find, think and check itself. Split the work into a router, a finder, an analyst and an independent checker. Connect them with a fixed map of steps. Search by both meaning and keywords. And record everything. You get answers people can act on.

The full design, with the technical choices behind each part, is in the Athena case study. If you have a similar problem, book a call and we can look at your data together.

Welcome to ByMoin. I’m Moin Dalal, an Agentic AI Developer & Architect, and this site is my home base. ByMoin is more than a portfolio. It is my personal signature on the AI systems I design and build for companies. These are AI agents that can plan and carry out tasks on their own, and they are built to run for real, not just in a demo.

Why I Built ByMoin

The name is deliberate. ByMoin means “by Moin Dalal”. It is a signature on every piece of work I produce. When you see the ByMoin name, you are looking at work I have personally designed, built and shipped. Many agencies hand out the same template to every client. ByMoin is a promise of the opposite: one person who is accountable, and work done with care.

As an Agentic AI Developer & Architect, my aim is simple. I build AI agent systems that companies actually put to work. We are past the days of fragile chatbots and weekend experiments. The companies I work with need AI that grows with them, keeps working, and fits deeply into their existing tools. It has to solve hard, day-to-day business problems. ByMoin exists to deliver that level of engineering.

The Tools I Trust

ByMoin starts with picking the right building blocks. You won’t find thin layers over someone else’s product here. Instead, I use proven tools that make real AI design possible:

• Agent flows: I use a tool for mapping an agent’s work as a flow of steps (LangGraph) to coordinate agents that remember where they are and can loop back (orchestration). It lets me lay out complex, multi-step work with the precision a company needs.
• Better instructions: Hand-writing instructions for a model is fragile. Tuning them with code is the better path. I use a framework that improves those instructions automatically (DSPy) to replace trial and error with a steady, repeatable method.
• Tool use: Building an agent is easy. Building one you can rely on is hard. A shared standard for how agents use outside tools (MCP) gives agents clear, fixed ways to use tools. That makes them sturdy and gives the same result for the same input (deterministic).
• Your own models: Some companies need to run their own models on their own servers. For them, I use an engine for running AI models fast on your own hardware (vLLM). It handles many requests at once (throughput) and answers quickly (latency), as ByMoin’s standards require.

What will you find on ByMoin?

This site is a living record of my work and what I learn along the way. It is where I document the path from idea to a live system.

Here you will find detailed case studies of my work, showing how I solve specific business problems. For example, you can explore the design behind Athena, a business intelligence system on my roadmap (planned, not built yet). You’ll also find deep dives into AI design, and regular blog posts on the trade-offs that come with building AI agents.

What Drives Me

My work has always been about closing the gap between what a technology could do and what it actually does for a business. What drives me is the impact of a well-designed system. I love taking a messy, complex business process and designing an AI agent system for it that simply works.

ByMoin is where that passion comes together. If you want to learn more about my own story, see the about me page.

In the end, ByMoin is a promise. The AI system you invest in will be built with intent, backed by deep know-how, and signed by Moin Dalal. Thank you for visiting, and I look forward to sharing more of this journey with you.