A cloud account can acquire a curious second life. It begins as a promise of speed: rent the computing power, launch the application, get on with the idea. Then come the permissions, inventories, maintenance jobs and bills. Before long, the people hired to build something are spending a considerable part of their day keeping the machinery in order. Venkat Krishnamachari has made that second life his business.
As MontyCloud’s co-founder and Chief Product Officer, he works on a problem with little natural glamour. Cloud operations rarely gets the applause reserved for a new application. Its reward is often an uneventful afternoon. Yet his career keeps returning to the people responsible for that afternoon, and to the possibility of giving them some of it back.
There is a pleasing companion detail in his earlier AWS author biography. Alongside his product management job, it records his enthusiasm for producing live theatre and music shows and volunteering with NGOs. Automation and live performance make an unusual pair. One tries to make a process repeatable; the other persuades people to turn up for something that will happen only once. Both require somebody to attend to the arrangements.
The maintenance job that became a career
Before MontyCloud, Krishnamachari worked inside the companies supplying the cloud itself. At Microsoft, he helped deploy Azure in Asian countries. At AWS, he worked on the Amazon EC2 Systems Manager team. These roles put him close to the practical business of making infrastructure usable, rather than simply available.
His 2017 AWS writing is a useful glimpse of the product manager at work. One article explained how Systems Manager Automation could become a target for CloudWatch Events. A team could start or stop computing instances on a schedule, or set a workflow in motion when something changed. The writing concerned small operational decisions that become substantial when repeated across an estate.
Another article examined delegated administration: allowing someone to carry out an approved operation through a tightly scoped service role. The aim was control as well as convenience. People should be able to perform the work they need to do without receiving an unnecessarily broad set of permissions. This interest in the boundary between access and responsibility would return in his later work on AI.
In October 2017, he co-wrote an announcement about version support in Parameter Store with AWS solutions architect Lou de la Torre. Configuration values could have identifiable iterations, giving teams a way to refer to a particular version. There is a certain poetry to a career built partly on helping people know exactly which setting they meant. Computers are literal creatures; somebody has to humour them.
A company for the morning after migration
In 2018, Krishnamachari, Kannan Parthasarathy and Venkat Hari founded MontyCloud. Their work crossed Seattle and Bangalore. By November 2019, the company had raised a $2.85 million seed round led by Madrona Venture Group, with Lytical Ventures and Bob Hammer of Hammer Ventures participating. Krishnamachari was its CEO.
The early proposition was practical. Customers needed to see what they owned across cloud accounts, understand how resources related to applications, and apply policies consistently. MontyCloud brought inventory, routine automation and governance into a management platform. The original announcement described an application-centred view, connecting infrastructure to the thing an organisation was actually trying to run.
That choice matters. A collection of servers is an inventory; an application is somebody’s service, project or promise to a customer. Organising operations around the latter gives a technical decision a purpose. The product’s job was to help teams keep that relationship visible while their infrastructure became harder to follow.
In April 2020, Krishnamachari announced the general availability of MontyCloud DAY2. He described cloud computing as a powerful, complex appliance, assembled from numerous services and settings. The name DAY2 neatly identified the territory: the ongoing work after getting an application into the cloud. A migration has a finish line. Maintenance has a calendar.
Four people get their projects back
In a 2021 interview, Krishnamachari offered a concrete example of what he wanted automation to accomplish. A customer had five people watching more than 10,000 servers for compliance requirements. He said that using compliance bots allowed four of them to move to other projects. The figure was a customer example he described, rather than a universal promise for every team.
Still, it makes his product argument unusually easy to picture. Four people had been assigned to the continuing business of checking. After automation, they could work elsewhere. The meaningful unit was a person with another project to do.
“What we do is we help IT teams simplify their cloud operations.”
Venkat Krishnamachari, 2021 interview

By April 2022, his own job had changed. Walter Rogers became CEO and Krishnamachari became Chief Product Officer. Raj Sivarajan joined to lead India operations. Krishnamachari welcomed Rogers’ experience growing technology businesses and improving customer experience. The founding product problem remained, with a different division of responsibilities around it.
The other production company
His interest in organising people predates MontyCloud. He co-founded the Seattle performance group IndusCreations in 2005 and later co-founded Ponmaalai, a volunteer music production team under the Seattle chapter of the Association for India’s Development. Its shows support education and village development through AID’s Eureka Focus Villages programmes.
These are collective enterprises. Their value comes from volunteers and donors putting their skills, time and resources together. They also give the technology résumé a welcome change of scenery. A cloud workflow ends in an operational result; a concert ends in applause, and then someone still has to put the equipment away.
It would be too tidy to claim that producing shows taught him how to build cloud software. The public record supports a more interesting coexistence: years spent making technical operations easier, alongside years spent helping people assemble cultural events for a practical purpose. In either setting, the arrangements matter because they allow other people to contribute.
Marvin enters the conversation
MontyCloud’s collaboration with the International Institute of Information Technology Hyderabad brought a new kind of interface to that operational problem. The teams developed a CloudOps Copilot, internally nicknamed Marvin. Rather than navigating multiple screens to find an answer, a user could ask a question.
The collaboration joined Parthasarathy and the MontyCloud team with researcher Karthik Vaidhyanathan and IIITH’s software engineering expertise. MontyCloud built workflows and a data pipeline; the research team helped develop the conversational agent. By December 2023, MontyCloud’s CEO and CPO were demonstrating the copilot at an AWS automation event.

The appeal was accessibility. Krishnamachari explained that automated checks could turn an architectural review into an actionable report, with Marvin helping bring that report to more users. The expert knowledge remained necessary. The interface offered a way for more people to use it.
In January 2025, Krishnamachari appeared among the co-authors of a paper describing MOYA, a multi-agent framework for autonomous CloudOps. The research tackled varied data sources, complex workflows and coordination between processes. It treated autonomy and human control as things to balance while building the system.
A dungeon master among the cloud architects
The research also escaped its original setting. In March 2025, Krishnamachari wrote about a MontyCloud-supported MOYA hackathon at IIIT Hyderabad involving more than 100 students. Participants used the framework for projects including a Dungeon Master agent and a meme generator. Infrastructure management had acquired an unexpectedly playful supporting cast.
The company’s involvement included mentoring, technical guidance and internship opportunities. One award went to a team that had begun without experience of agentic frameworks. The exercise gave the builders feedback on their tool while giving students something tangible to experiment with. A research framework can look quite different once someone asks it to run a game.
Later that year, his September announcement of MontyCloud AI described an expanded assistant and workflows connecting operations to other business tools. Examples included turning a security alert into a Jira ticket or a discovered opportunity into a HubSpot entry. The scope had moved beyond answering a question to carrying work into the systems where teams follow it up.
That expansion makes the next question unavoidable. Once software can do more, someone has to decide how much it should be allowed to do.
The permission slip needs evidence
In August 2026, Krishnamachari published a two-part account of the CloudOps Competency Benchmark, developed with IIIT Hyderabad researchers. His organising idea was that an AI system should earn operational authority for defined work under defined conditions. A convincing demonstration would not, by itself, settle the matter.
“Autonomy in CloudOps should be earned level by level.”
Venkat Krishnamachari, August 2026
The framework separates retrieving information, analysing it, recommending a response, executing bounded changes and operating within an approved goal. The distinctions preserve a place for judgment. Being useful at analysis does not automatically establish that a system is ready to change a live environment.
CCB / Five levels of earned autonomy
- RetrieveBring back information
- AnalyseExplain what the evidence shows
- RecommendPropose a course of action
- Execute within boundsMake permitted changes
- Operate toward a goalObserve, act and verify within policy
Authority applies to a specific task and environment. These are evaluation levels, not a rating of MontyCloud’s product.
The second instalment described a corpus of more than 600 scenarios across 13 CloudOps categories. It also drew a clear boundary around the initial empirical study: 40 AWS scenarios at the first two levels. The public release covered those scenarios; the wider corpus was available to researchers on request. The distinction gives the ambition a measurable starting point.
MontyCloud had announced a Series B led by Riverside Acceleration Capital in January 2026, with plans to invest in its platform and expand its global commercial work. For Krishnamachari, the continuing product challenge is visible in the gap between a system’s growing abilities and the evidence needed to trust them.
His career has spent years opening that space carefully: permissions that let a person do a job, automation that releases a team for other projects, interfaces that make specialist knowledge easier to use. Offstage, there are shows to produce. On the cloud side, there are systems to check. In both cases, the interesting part begins when the arrangements let somebody else get on with their work.
Follow the work
- MontyCloud - company and leadership ↗
- Venkat on LinkedIn ↗
- Venkat’s product writing ↗
- Watch: theCUBE conversation, 2021 ↗
- Read: his AWS automation article, 2017 ↗
- Read: MontyCloud’s seed round, GeekWire ↗
- Read: the IIIT Hyderabad collaboration ↗
- Research: the MOYA multi-agent paper ↗
- Read: the MOYA student hackathon ↗
- Read: the CloudOps Competency Benchmark series ↗
- Read: inside the benchmark ↗
- News: MontyCloud’s January 2026 Series B ↗