Almost every conversation we have about AI starts in the same place: a company with a serious .NET estate, years of business logic in it, and a board asking what the AI plan is. The temptation is to start a new project next to the old one. In our experience that is the slow path. The fast path is to make the system you already have usable by a model, one capability at a time.
What “agentic” actually changes
A chatbot answers questions. An agent takes actions: it reads a record, calls a service, writes something back, and decides what to do next based on the result. The model is the planner; your application supplies the tools. That inversion is the whole architecture. The model never touches your database directly. It calls functions you wrote, with inputs you validate, under permissions you control.
This is good news for a .NET shop, because you already have the functions. A well-factored service layer is most of an agent’s toolset.
Where the agent sits
We put the agent in its own service, not inside the web application or an existing API. It owns three things:
- The conversation loop. Send the user’s request and the available tools to the model, receive either an answer or a tool call, execute the tool, return the result, repeat until the model is done.
- The tool registry. A list of callable operations with names, descriptions and JSON schemas for their inputs. Each one wraps an existing service method.
- Policy. Which tools this user, in this context, is allowed to call; what needs confirmation; what is logged.
Keeping that in one service means the rest of the system does not know or care that a model is involved. Your order service is called by the agent exactly as it is called by the checkout page.
Exposing existing code as tools
A tool is a method with a schema. In .NET the quickest route is to describe each tool with a small record (name, description, input type) and generate the JSON schema from the input type with System.Text.Json source generation or a schema library. Descriptions matter more than people expect: the model chooses tools by reading them, so “Get the open orders for a customer, most recent first” is a better description than “GetOrders”.
Start with read-only tools. Looking up a customer, listing orders, checking stock, searching a knowledge base. Those let you see how the model reasons about your domain with no risk. Add write tools once you trust the behaviour, and gate each one: a write tool should validate its input as strictly as a public API endpoint, because from a security point of view that is what it is.
Where MCP fits
The Model Context Protocol (MCP) is a standard way to publish tools so that any compatible client, including Claude and most agent frameworks, can discover and call them. If you build your tool layer as an MCP server, you get two things for free: a stable contract between your systems and whichever model you use, and the ability to use the same tools from desktop assistants, internal copilots and automated agents without re-integrating each time.
In practice we build the MCP server as a thin .NET host over the same service layer: one process, a handful of tool definitions, authentication in front. It is the integration surface for AI the way a REST API is the integration surface for partners.
Retrieval before generation
If your use case involves answering from company material, the quality of the answers is decided by retrieval, not by the model. Chunk documents sensibly, store metadata (type, date, audience), index with full-text and vector search, and return the top passages with their sources. Ask the model to answer only from those passages and to cite them. This is retrieval-augmented generation, and it is the difference between an assistant people trust and one they stop using after a week. It also keeps your data where it is: the model sees a few passages per question, not your archive.
What to guard
- Prompt injection. Anything the model reads, including a document or an email, can contain instructions. Treat tool results as data. Never let retrieved content change what tools are available or what the user is allowed to do.
- Cost and latency. Agent loops can run long. Set a maximum number of steps, a token budget per request and a timeout. Cache retrieval results and tool outputs where it is safe.
- Observability. Log every tool call with its inputs and outputs. When something goes wrong you need the transcript, not a guess.
- Human confirmation. For anything irreversible, the agent proposes and a person confirms. This is not a limitation; it is how you get adoption.
A sensible first project
Pick one workflow that is high-volume, well understood and mostly reading: answering support questions from documentation, or helping sales find the right product for a customer’s situation. Build the tool layer, the retrieval index and the agent service, and put it in front of an internal team first. You will learn more in two weeks of real use than in two months of planning, and everything you build is reusable for the next workflow.
That is the shape of most of our AI engagements: no new platform, a small service that makes the existing one callable, and a first workflow in production within a quarter.
Have a similar problem?
Tell us what you are building. Hiten reads every enquiry and replies within one working day.