Agent Server [2/3]: Where Should Your Agent Server Run?

‍

Where does it run? Where is it deployed? In the world of software, people used to deploy software through floppy disks and CD-ROMs. They would ship you. That felt very secure because it was running on your computer and it was very clear that the vendor of that software had no ability to generally access that software or see what you're doing with it. The world of software as a service, SaaS, obviously changed that quite a bit because now the software and SaaS world is running somewhere else in a place that the vendor of the SaaS operation has to secure and that you as a user of that have to become comfortable with.

Agents Replacing SaaS Applications

Agents are starting to obviate the need for certain classes of SaaS applications. That's kind of one of the potential benefits and cost savings that agents might allow is the ability to not use as much SaaS or slow the growth rate of that because those agents can do things internally to an organization that those companies used to depend on SaaS vendors to do. So that means that those agents, though, have to run somewhere.

Genesis Approach: Running Agents Inside Customer Environment

There's various places an agent could run, where the agent server could run. It could be back at a SaaS vendor. There are companies that run whole turnkey SaaS systems effectively for agents that do certain things, marketing things or legal things. However, at Genesys, we're doing data agents, things that do stuff with data. Data, obviously one of the key assets of any corporation. And in our experience, we found that our customers want those data agents, the servers for those agents, to run inside the customer's environment. ideally on the same platform where the data itself is resident. It makes it a lot easier to secure and understand why it's secure versus having agents running somewhere else that have to reach into your corporate data.

Deployment Options for Genesis Agent Server

So assuming a customer wants to deploy a data agent inside their environment, not outside, which is the way that all of our Genesys customers do it inside their environment, there's a couple of places where you can run it. Our agent server is a Docker container, effectively. So that means that it can be run anywhere that the customer of Genesys is comfortable running Docker containers. Most people, most large enterprises are running lots of containers for lots of things. They're generally pretty comfortable with that concept.

Data Platform Deployment

And the kind of biggest, most useful places to run agent servers are inside of your data platform itself. The Snowflake container, Snowpark container services and Snowflake makes that especially easy. Genesys has a Snowflake native application that comes with a set of Snowpark container services, which is our Gen, Genesys agent server running inside those containers. So running it inside your Snowflake account if you're a Snowflake customer is a good, easy path. And that gives you a lot of security around it because you kind of inherit all the stuff you already trust Snowflake for because Snowflake is running around that. Databricks has similar abilities to run containers inside the Databricks platform.

Cloud Provider Deployment

And then most of our customers are either AWS or Azure shops. And generally there are comfortable running applications and containers inside either their AWS deployment by EC2 or via ECS. And we have Terraform deployment scripts that allow easy deployment of our server into those kind of AWS environments. Or on the Azure side, people can run our system as in Azure containers or in Azure VMs. And we, again, have Terraform deployment scripts that can set everything up on the Azure side.

On-Premise and Kubernetes Deployment

The other last option is to run it somewhere else. So if somebody has a Kubernetes cluster, you could even on-premise, some hedge funds have on-premises Kubernetes clusters, and they want to run everything literally inside their building still. And that's fine too. So our software, because it comes as a container, it can run in any of these different environments, all of which from a security and access control perspective are generally seen as better than running running an agent in somebody else's cloud somewhere else in some other vendor where you have to be concerned about all of their security protocols.

Why Enterprise Deployment Matters for Data Agents

And doubly concerned in this case because for a data agent, ideally you give it pretty broad access to the data sets of your organization, both structured and unstructured data. Much broader access than you would normally give to a SaaS platform. SaaS platforms generally are creating a lot of the data inside the SaaS platform itself. Like Salesforce, you create a lot of the data inside Salesforce. Whereas here in terms of agents, especially data agents, they're accessing data that's already resident inside your enterprise and potentially large amounts and large breadth of that kind of data. So running agent platforms, especially for data agents inside the enterprise environment in a place that is already trusted and secured and monitored by each enterprise, is generally the best way to deploy agents these days.

Access Control for Data Agents

Access control for data agents. When you're thinking about how to secure data agents, there's two different sets of things to think about. One is the access that the agents themselves have to enterprise systems and underlying data sets. And the other is users' ability to access those agents and what the users can do the agents.

Treating Agents as People

So the way we find it most useful is to consider the data agents to be effectively people and to give them access rights to each agent as if that agent was a person. So you'd set up in your Snowflake system, for example, or Databricks system, or any system, JIRA, GitHub, et cetera, that an agent needs to interact with, Google Drive, SharePoint. You'd set up a account for that agent, either as a person or as a service account, depending on how your organization is starting to think about how to classify these non-human users. But you give them some form of access key or access account.

Then in the genesis system, the agent server, you would assign each agent, you can have more than one agent for different roles and responsibilities. You give the access to the agent. Then that agent is able to use that access to look at GitHub, look at JIRA, run queries on Databricks, run queries on Snowflake, run Python on Snowpark, run Python on DRX, what have you. So giving the agent that access, and then you can monitor that agent's activity the same way you would monitor a human's activity.

Appropriate Access Levels for Data Agents

In terms of what kind and level of access to give a data agent, generally, you would think about giving them the same type of access you would give to a new employee. Generally, that comes with limits of their access. Obviously, you don't want to give just full administrative access to the entire system to an agent on day one, the same way you wouldn't do the same thing to a new employee generally on day one. So, being thoughtful about what access you give to each agent. You could read access to certain data sets, write access to certain play spaces or schemas, things like that. That's the first thing to think about.

Role of the Agent Server

The agent server that we've discussed in other videos is the thing that receives that access and securely manages the rights and roles and the keys and all that, that the agent will be using.