Agent deployments need long-running execution, pause and resume support, state, memory, and ways for agents to inspect their own work.
2
Agentuity treats agents as infrastructure objects and handles routing, runtimes, networking, inputs, outputs, sessions, and deployment.
3
The live demo shows a framework-agnostic workflow using templates, local development, observability, GitHub deployment, and connections to email, SMS, APIs, and cron jobs.
Summary
Rick Blalock describes deployment problems he saw among University of Florida students and while building a qualitative research agent. Serverless platforms caused timeouts for long-running agents, while gateway and networking setup made it difficult to connect agents. Web infrastructure also assumes stateless requests, while agents often need state, memory, pausing, resuming, and code execution. He demonstrates Agentuity, which supports Bun, Python with UV, and Node.js, and can run agents built with frameworks such as Vercel AI SDK, Mastra, CrewAI, LangChain, and Pydantic. The platform provides routing, internal agent calls, ephemeral tokens, local development, public tunneling, logs, traces, cost data, and deployment in a specialized container. Inputs can be connected through email, SMS, APIs, or cron jobs. Blalock is candid about a failed demo caused by an insufficient memory setting. He also describes planned infrastructure agents that monitor logs and surface issues.
Serverless deployments break down when agents run for minutes
Rick Blalock says students and professors repeatedly identified deployment as their main agent problem. They built agents on AWS Lambda, then ran into timeouts when an agent needed 15 or 30 minutes. Agentuity itself has an internal agent that runs for about 40 minutes a day. The students were not allowed to use VMs or EC2, so they also faced limits on where these workloads could run. Blalock describes similar trouble from his own qualitative research agent, which performed synthesis and took long enough that he had to re-architect the serverless design.
Agents need runtime features that ordinary web services often omit
Blalock lists the runtime behavior he thinks agents need: they must run as long as necessary, pause, stop, and resume. Their inputs and outputs should be decoupled from the agent code and support different forms. He also calls for introspection, self-observability, and self-reflection. Standard human-facing observability gives people traces and spans, but Blalock says agents need to understand those signals too. He adds memory, evolution, and code execution to the requirements. These needs explain why a conventional stateless web deployment can become a poor fit for agent workloads.
Agentuity makes the agent an infrastructure object
In the live setup flow, Blalock creates a project and an agent with the Agentuity CLI. He describes a project as a grouping of agents and something that can map one-to-one to a GitHub repository. Agents are first-class infrastructure objects in the platform, so Agentuity handles routing to them. Access can be protected at the project level or with an API key for each agent. A GitHub connection can also trigger deployment when the main branch is merged. The example uses Bun with a Vercel AI SDK and Grok template, while the platform also supports Python with UV and Node.js.
The platform keeps framework choices separate from deployment
Blalock says Agentuity is framework agnostic. A project can contain agents built with different frameworks, such as CrewAI, LangChain, Pydantic, Vercel AI, or Mastra, and those agents can talk to each other through internal networking. The code conventions stay small: a YAML file configures the deployed agent, an agents folder contains the implementation, and the agent exposes an entry point. In JavaScript, the entry point is a default request handler. In Python, the developer declares a run function. Agentuity places routed requests on the request object and exposes context methods for getting another agent.
The Agentuity dev command runs projects locally and assigns ports when there are multiple projects. Blalock shows public routing through a tunnel, which lets another service call an agent during development. The development simulator accepts more than text, including JSON, HTML, and PDFs, while email support is available elsewhere in the product. Developers can inspect terminal logs, sessions, traces, prompts, responses, and model-call costs. Blalock says the development view is intended to mirror production, so the same observability information is available after deployment.
Inputs and outputs can be attached after the agent is built
After deploying the sample agent in a specialized Bun container, Blalock shows project-level controls for cost breakdowns by project, agent, and run. He then adds an email input and receives an address for the agent. The same pattern can support SMS, APIs, and cron jobs. This lets a developer build the agent first and connect a particular interface later. Blalock describes a workflow where another user can deploy from the GitHub repository and then wire up email or another input without changing the agent's core implementation. Slack and Discord connections are mentioned as planned additions.
Blalock sends a request to the public webhook and gets a session ID, but the agent fails to run because the configured memory footprint is too small in the YAML file. He identifies the setting as something that needs changing and says it is also an area Agentuity is working on. The failure matters because it shows the kind of ordinary infrastructure issue the product is meant to surface and manage. Blalock does not hide the broken run, and the session logs make the failed deployment visible.
Agentuity plans infrastructure agents that watch application logs
Blalock says Agentuity has 50 or 60 internal agents running on the platform and that the company is getting better development velocity from using it. He describes the current product as the first part of an agent-native cloud suite. The next work includes infrastructure agents that watch logs and surface issues for developers and the Agentuity team. He jokes that the system could be called 'agent duty' instead of PagerDuty because agents would handle that operational work. In the question period, he also says he needs tool calling for a CRM agent under development.
"We want to offer that as a services layer from an infrastructure services perspective, where a lot of that stuff you just get out of the box."13:48
Who should watch
You are deploying agents on serverless infrastructure and are running into timeouts, state management, or networking problems.
Your team uses several agent frameworks and wants them to communicate through a common deployment layer.
You need to connect agents to email, SMS, APIs, or scheduled jobs while keeping logs, sessions, and model costs visible.
