Vamshidhar Parupally has been working on a tense little moment in software: the last check before code goes live.

By the time a pull request reaches production review, the work has already passed through a lot of hands. Still, someone has to put their name behind it. A senior engineer opens the diff, reads the changed paths, and looks for the bug that only shows up later or the permission check that got lost in the rush. On a good day, the review is careful. On a tight one, it becomes triage.

Parupally, a software engineer at ServiceNow in Santa Clara, built a different kind of review loop. His system runs code changes past three AI agents. The first acts like a developer, checking for bugs and code quality issues. The second reads like a senior engineer, weighing design and architectural choices. The third takes the architect's view, looking at how the change fits into the wider system. Each agent writes a structured assessment. The final answer is blunt: GO or NO-GO. A human can still trace the reasoning behind each layer instead of taking the model's word for it.

That project fits into work Parupally has been doing since he joined ServiceNow in 2024, and in pieces he has written for DZone. The industry label is agentic AI, a phrase that sounds heavier than the thing itself. To get it, start with the model most companies adopted first: Retrieval-Augmented Generation, or RAG.

For the past couple of years, RAG has been the default shape for enterprise AI. A user asks a question. The system pulls matching material from a database, wiki, document store, or ticket archive. The model writes an answer from that material. This fixed a real problem, because early language models could sound certain while being wrong. Grounding the answer in company data helped. It also left the system waiting for the next prompt.

Agentic AI changes the unit of work from a question to a goal. An agent can break the goal into steps, choose a tool, call it, read the result, and decide what to do next. If a database query fails, it can rewrite the query. If tests break, it can read the stack trace, patch the code, and run the suite again. It keeps going until the work is done or a guardrail tells it to stop.

That style of system runs into an unglamorous problem fast. Enterprise software was built around people, scripts, credentials, and service accounts. Agents ask it to behave another way. A company's Jira, code repository, monitoring stack, databases, and internal APIs all have their own protocols and return formats. Early agent builds needed custom glue for every connection. Add a tool, write another integration. After a few of those, the maintenance burden starts to define the project.

Parupally's answer has been to build around the Model Context Protocol, or MCP. In his writing, he compares it to USB-C. The point is a common interface: the agent talks to one protocol, while the tools handle their own details behind that boundary. The agent doesn't need special knowledge of one Jira instance or a hand-written path into a particular PostgreSQL database. The tool exposes itself through MCP, and the agent sees the same shape every time.

With that layer in place, a team can run one MCP server for ticketing, another for source control, and another for logs or alerts. The agent can cross those systems in one workflow without a developer wiring every hop from scratch.

His open-source project ctxlint deals with a smaller, sharper failure. Agents depend on context files, the documents that tell them which tools exist, which commands are valid, and which resources they can use. When those files drift from reality, the agent starts calling dead tools or looking for moved files. Ctxlint checks the context before the agent receives it, catching broken paths and stale commands the way a compiler catches bad syntax before a build ships.

ServiceNow is a natural place to work on this because it already sits inside the IT operations of thousands of companies. A server goes down. A security alert fires. The incident reaches the platform before most people have opened an inbox. Parupally has worked on agents that can read those incidents, query related logs, draft summaries, and route tickets without a person sitting at the keyboard. For operations teams, the math is plain: shorter resolution times, fewer manual handoffs, less queue-juggling when everything is already on fire.

The quiet part is the infrastructure work underneath it. The agent has to know what it can touch, how far it can go, and when a human needs to step in. If that layer works, nobody thinks much about it. They just see the ticket move, the summary arrive, and the incident close a little sooner than it used to.