Building production-grade agentic AI applications isn’t just about assembling components. It takes deep expertise to design workflows that align business needs with technical complexity.
AI teams must evaluate countless configurations, balancing LLMs, smaller models, embedding strategies, and guardrails, while meeting strict quality, latency and cost objectives.
But developing agentic AI applications is only half the battle.
AI teams often face challenges handing projects off to DevOps or MLOps teams to stand up the experience, integrating them into existing tools and workflows, and managing monitoring, governance, and complex GPU infrastructure at scale.
Without the right structure, agentic AI risks getting stuck in endless iterations.
But when done right, agentic AI becomes more than just another application. It’s a transformative force empowering teams to build scalable, intelligent solutions that drive innovation, efficiency, and unprecedented business value.
To make that leap, AI teams need more than just AI tools. They need a structured, scalable way to develop, deploy, and manage agentic AI efficiently.
Agentic AI can transform enterprise workflows, but most teams struggle to move from prototype to production. The challenge isn’t just building an agent — it’s scaling infrastructure reliably, delivering real value, and maintaining trust in the outputs as usage grows.
To succeed, AI teams need more than disconnected tools. They need a simple, unified, end-to-end approach to development, deployment, and management.
Together, DataRobot and NVIDIA provide a pre-optimized AI stack, advanced orchestration tools, and a robust development and deployment environment, helping teams move faster from prototype to production while maintaining security and enterprise readiness from day one.
Here’s what this looks like.
The DataRobot agentic AI platform provides an end-to-end platform to orchestrate and manage the entire agentic AI lifecycle, enabling developers to build, deploy, and govern AI applications in days instead of months.
With DataRobot, users can:
With NVIDIA AI Enterprise fully embedded into DataRobot, organizations can:
Follow this step-by-step process for using DataRobot and NVIDIA AI Enterprise to build, operate, and govern your agentic AI quickly and efficiently.
Step 1: Browse NVIDIA NIM gallery and register in DataRobot
Access a full library of NVIDIA NIM directly within the DataRobot Registry. These pre-tuned, pre-configured components are optimized for NVIDIA GPUs, giving you a high-performance foundation without manual setup.
When imported, DataRobot automatically applies versioning and tagging, so you can skip setup steps and get straight to building.
To get started:
Step 2: Select a DataRobot app template
Start compiling and configuring your agentic AI app with pre-built, customizable templates that eliminate setup work and let you go straight into prototyping, testing, and validating.
The DataRobot app library provides frameworks designed for real-world deployment, helping you get up and running quickly.
Step 3: Open your NVIDIA NIM into DataRobot Workbench to build and optimize your VDB
With your app template in place and hardware selected, it’s time to bring in the generative AI component and start building your vector database (VDB) in the DataRobot Workbench.
Step 4: Test and evaluate NVIDIA NIM LLM configurations in the LLM Playground
In DataRobot’s LLM Playground, you can quickly build, compare, and optimize different RAG workflows and LLM configurations without tedious manual switching.
Here’s how to test and refine your setup:
Step 5: Add predictive elements to your agentic flow
(If your app uses only generative AI, you can move on to packaging with guardrails and final testing.)
For agentic AI apps that incorporate forecasting or predictive tasks, DataRobot streamlines the process with its built-in predictive AI capabilities.
DataRobot will automatically:
Then you can:
Step 6: Add the right tools to your app
Expand your app’s capabilities by integrating additional tools and agents, such as the NVIDIA AI Blueprint for video search and summarization (VSS), to process video feeds and transform them into structured datasets.
Here’s how to enhance your app:
Step 7: Add monitoring and safety guardrails
Guardrails are your first line of defense against bad outputs, security risks, and compliance issues. They help ensure AI-generated responses are accurate, secure, and aligned with user intent.
Here’s how to add guardrails to your app:
Step 8: Design and test your app’s UX
A well-designed UX makes your AI app intuitive, valuable, and easy to use. With DataRobot, you can stage a complete version of your app and test it with end users before deployment.
Here’s how to test and refine your UX:
Step 9: Deploy your agentic AI app with one-click
With one-click deployment, you can instantly launch NVIDIA NIMs from the model registry without manual setup, tuning, or infrastructure management.
Your app, guardrails, and monitoring are deployed together, ensuring full traceability and governance.
Here’s how to deploy:
Step 10: Monitor and govern your deployment in DataRobot
After deployment, your AI app requires continuous monitoring to ensure long-term stability, accuracy, and performance. NIM deployments use DataRobot’s observability framework to surface key metrics on health and usage.
The DataRobot Console provides a centralized view to:
Complex AI projects often stall due to repetitive manual work — swapping components, tuning combinations, and re-running tests to meet evolving requirements. Without clear visibility or structured workflows, teams can easily lose track of what’s working and waste time redoing the same steps.
Best practices to reduce friction and maintain momentum:
By following these practices, you and your team can move faster, stay aligned, and avoid the iteration trap that slows down real progress.
Agentic AI has massive potential, but its impact depends on delivering it efficiently and ensuring trust in production.
With DataRobot and NVIDIA AI Enterprise, teams gain:
Whether you’re launching your first agentic AI app or scaling a portfolio of enterprise-grade solutions, this platform gives you the speed, structure, and reliability to turn innovation into real business results.
Ready to build? Book a demo with a DataRobot expert and see how fast you can go from prototype to production.
The post How to build and scale agentic AI with DataRobot and NVIDIA appeared first on DataRobot.
Kick-off in a Small Size League match. Image credit: Nicolai Ommer.
RoboCup is an international scientific initiative with the goal of advancing the state of the art of intelligent robots, AI and automation. The annual RoboCup event is due to take place from 15-21 July in Salvador, Brazil. The Soccer component of RoboCup comprises a number of Leagues, with one of these being the Small Size League (SSL). We caught up with Executive Committee member Nicolai Ommer to find out more about the SSL, how the auto referees work, and how teams use AI.
In the Small Size League (SSL) we have 11 robots per team – the only physical RoboCup soccer league to have the full number of players. The robots are small, cylindrical robots on wheels and they can move in any direction. They are self-built by the teams, so teams have to do both the hardware and the programming, and a lot of things have to work together to make a team work. The AI is central. We don’t have agents, so teams have a central computer at the field where they can do all the computation and then they send the commands to the robots in different abstractions. Some teams will just send velocity commands, other teams send a target.
We have a central vision system – this is maintained by the League, and has been since 2010. There are cameras above the field to track all the robots and the ball, so everyone knows where the robots are.
The robots can move up to 4 meters per second (m/s), after this point it gets quite unstable for the robots. They can change direction very quickly, and the ball can be kicked at 6.5 m/s. It’s quite fast and we’ve already had to limit the kick speed. Previously we had a limit of 8 m/s and before that 10m/s. However, no robot can catch a ball with this speed, so we decided to reduce it and put more focus on passing. This gives the keeper and the defenders a chance to actually intercept a kick.
It’s so fast that for humans it’s quite difficult to understand all the things that are going on. And that’s why, some years ago, we introduced auto refs, which help a lot in tracking, especially things like collisions and so on, where the human referee can’t watch everything at the same time.
When we developed the current system, to keep things fair, we decided to have multiple implementations of an auto ref system. These independent systems implement the same rules and then we do a majority vote on the decisions.
To do this we needed a middle component, so some years ago I started this project to have a new game controller. This is the user interface (UI) for the human referee who sits at a computer. In the UI you see the current game state, you can manipulate the game state, and this component coordinates the auto refs. The auto refs can connect and report fouls. If only one auto ref detects the foul, it won’t count it. But, if both auto refs report the foul within the time window, then it is counted. Part of the challenge was to make this all visual for the operator to understand. The human referee has the last word and makes the final decision.
We managed to establish two implementations. The aim was to have three implementations, which makes it easier to form a majority. However, it still works with just two implementations and we’ve had this for multiple years now. The implementations are from two different teams who are still active.
We can detect collisions from the data. However, even for human referees it’s quite hard to determine who was at fault when two robots collide. So we had to just define a rule, and all the implementations of the auto ref implement the same rule. We wrote in the rulebook really specifically how you calculate if a collision happened and who was at fault. The first consideration is based on the velocity – below 1.5m/s it’s not a collision, above 1.5m/s it is. There is also another factor, relating to the angle calculation, that we also take into account to determine which robot was at fault.
Other fouls include the kick speed, and then there’s fouls relating to the adherence to normal game procedure. For example, when the other team has a free kick, then the opposing robots should maintain a certain distance from the ball.
The auto refs also observe non-fouls, in other words game events. For example, when the ball leaves the field. That’s the most common event. This one is actually not so easy to detect, particularly if there is a chip kick (where the ball leaves the playing surface). With the camera lens, the parabola of the ball can make it look like it’s outside the field of play when it isn’t. You need a robust filter to deal with this.
Also, when the auto refs detect a goal, we don’t trust them completely. When a goal is detected, we call it a “possible goal”. The match is halted immediately, all the robots stop, and the human referee can check all the available data before awarding the goal.
My first RoboCup was in 2012. The introduction of the auto refs has made the play a lot more fluent. Before this, we also introduced the concept of ball placement, so the robots would place the ball themselves for a free kick, or kick off, for example.
From the hardware side, the main improvement in recent years has been dribbling the ball in one-on-one situations. There has also been an improvement in the specialized skills performed by robots with a ball. For example, some years ago, one team (ZJUNlict) developed robots that could pull the ball backwards with them, move around defenders and then shoot at the goal. This was an unexpected movement, which we hadn’t seen before. Before this you had to do a pass to trick the defenders. Our team, TIGERs Mannheim, has also improved in this area now. But it’s really difficult to do this and requires a lot of tuning. It really depends on the field, the carpet, which is not standardized. So there’s a little bit of luck that your specifically built hardware is actually performing well on the competition carpet.
The Small Size League Grand Final at RoboCup 2024 in Eindhoven, Netherlands. TIGERs Mannheim vs. ZJUNlict. Video credit: TIGERs Mannheim. You can find the TIGERs’ YouTube channel here.
One big challenge, and also maybe it’s a good thing for the League, is that we have a lot of undergraduate students in the teams. These students tend to leave the teams after their Bachelor’s or Master’s degree, the team members all change quite regularly, and that means that it’s difficult to retain knowledge in the teams. It’s a challenge to keep the performance of the team; it’s even hard to reproduce what previous members achieved. That’s why we don’t have large steps forward, because teams have to repeat the same things when new members join. However, it’s good for the students because they really learn a lot from the experience.
We are continuously working on identifying things which we can make available for everyone. In 2010 the vision system was established. It was a huge factor, meaning that teams didn’t have to do computer vision. And we are currently looking at establishing standards for wireless communication – this is currently done by everyone on their own. We want to advance the League, but at the same time, we also want to have this nature of being able to learn, being able to do all the things themselves if they want to.
You really need to have a team of people from different areas – mechanical engineering, electronics, project management. You also have to get sponsors, and you have to promote your project, get interested students in your team.
Most of our software is script-based, but we apply machine learning for small, subtle problems.
In my team, for example, we do model calibration with quite simple algorithms. We have a specific model for the chip kick, and another for the robot. The wheel friction is quite complicated, so we come up with a model and then we collect the data and use machine learning to detect the parameters.
For the actual match strategy, one nice example is from the team CMDragons. One year you could really observe that they had trained their model so that, once they scored goal, they upvoted the strategy that they applied before that. You could really see that the opponent reacted the same way all the time. They were able to score multiple goals, using the same strategy again and again, because they learned that if one strategy worked, they could use it again.
For our team, the TIGERs, our software is very much based on calculating scores for how good a pass is, how well can a pass be intercepted, and how we can improve the situation with a particular pass. This is hard-coded sometimes, with some geometry-based calculations, but there is also some fine-tuning. If we score a goal then we track back and see where the pass came from and we give bonuses on some of the score calculations. It’s more complicated than this, of course, but in general it’s what we try to do by learning during the game.
People often ask why we don’t do more with AI, and I think the main challenge is that, compared to other use cases, we don’t have that much data. It’s hard to get the data. In our case we have real hardware and we cannot just do matches all day long for days on end – the robots would break, and they need to be supervised. During a competition, we only have about five to seven matches in total. In 2016, we started to record all the games with a machine-readable format. All the positions are encoded, along with the referee decisions, and everything is in a log file which we publish centrally. I hope that with this growing amount of data we can actually apply some machine learning algorithms to see what previous matches and previous strategies did, and maybe get some insights.
We have actually won the competition for the last four years. We hope that there will be some other teams who can challenge us. Our defence has not really been challenged so we have a hard time finding weaknesses. We actually play against ourselves in simulation.
One thing that we want to improve on is precision because there is still some manual work to get everything calibrated and working as precisely as we want it. If some small detail is not working, for example the dribbling, then it risks the whole tournament. So we are working on making all these calibration processes easier, and to do more automatic data processing to determine the best parameters. In recent years we’ve worked a lot on dribbling in the 1 vs 1 situations. This has been a really big improvement for us and we are still working on that.
|
Nicolai Ommer is a Software Engineer and Architect at QAware in Munich, specializing in designing and building robust software systems. He holds a B.Sc. in Applied Computer Science and an M.Sc. in Autonomous Systems. Nicolai began his journey in robotics with Team TIGERs Mannheim, participating in his first RoboCup in 2012. His dedication led him to join the RoboCup Small Size League Technical Committee and, in 2023, the Executive Committee. Passionate about innovation and collaboration, Nicolai combines academic insight with practical experience to push the boundaries of intelligent systems and contribute to the global robotics and software engineering communities. |