# How to build OpenAI Agents that act inside your real apps with schedules, guardrails and Kubernetes

Build OpenAI Agents that run in Slack, Gmail, Docs and Calendar: natural-language planning, LLM-as-judge guardrails, Inngest queue and KEDA autoscaling.

Source: https://lanlan123.top/how-to-build-openai/ · based on the channel [Mir Mueed](https://www.youtube.com/channel/UC1q70z6lnLvWjP0EkQ9EahA) · Video: [AMIGO AI – Build AI Agents That Work in Your Real Apps (Next.js, OpenAI Agents SDK, Kubernetes)](https://www.youtube.com/watch?v=O_N1sEZNtMQ) · 2026-10-27

![How to build OpenAI Agents that act inside your real apps with schedules, guardrails and Kubernetes](https://lanlan123.top/how-to-build-openai/how-to-build-openai.webp)

## Key takeaways

- AMIGO AI generates an agent from one plain-English request: Gemini plans the goal, steps, target apps and schedule.
- Runs are scheduled, on-demand or chat-triggered, with a live run history and 4 agents executed in parallel in the demo.
- Guardrails use an LLM-as-judge: input screening for prompt injection, PII and phishing, output review for leaked secrets and unsupported claims.
- Stack: Next.js, TypeScript, OpenAI Agents SDK, Google Gemini, Composio, Inngest, PostgreSQL on Neon, Drizzle ORM, Docker and Kubernetes.
- KEDA scales the worker from 1 to 5 pods by queue depth; a CronJob handles cleanup and logs are structured JSON.

OpenAI Agents become genuinely useful when they stop living in a chat window and start executing work inside the tools you already use. AMIGO AI, an open-source platform by developer Mir Mueed, does exactly that: you describe a task in plain English, and it generates an agent that posts to Slack, writes Google Docs, books Google Calendar events, sends Gmail and touches Notion, GitHub or WhatsApp Business — on a schedule, on demand or from a chat message. The full code and architecture notes are on GitHub in the [AMIGO AI repository](https://github.com/mueed26/AMIGO-AI), so you can clone it and run the same setup yourself.

## What OpenAI Agents need to work inside real apps

An agent that only reasons is a demo; an agent that acts is a product, and acting requires four separate layers. First, a planner that turns a natural-language request into a concrete goal, a list of steps, the apps involved and a schedule — AMIGO AI delegates this to Google Gemini. Second, an executor built on the OpenAI Agents SDK that calls real integrations through Composio, which supplies authenticated connectors for Slack, Gmail, Google Docs, Google Calendar, Notion, GitHub and WhatsApp Business. Third, a durable job layer so runs survive restarts and retries: Inngest handles the background queue with retries. Fourth, a safety layer that inspects both what goes into the model and what comes out of it. Skipping any one of these layers is why most agent prototypes never reach production.

## How AMIGO AI turns one sentence into a scheduled agent

The generation flow is a single request followed by a structured plan. When you type something like “every Monday, summarize last week's GitHub activity and post it to Slack,” the planner returns a machine-readable spec: the goal, ordered steps, the required apps and a cron-like schedule. That spec is stored in PostgreSQL (hosted on Neon and accessed through Drizzle ORM) and rendered as an agent you can edit before activation. From there the agent supports three trigger modes:

1. Scheduled runs, fired by the queue on the cadence defined in the spec.
2. On-demand runs, started manually from the dashboard.
3. Chat-based runs, where you message the agent and it performs a live action immediately.

Every execution writes to a run history, so you can see which step failed and what each tool call returned. In the demo, four agents run in parallel and produce real artifacts: a Slack post, a Google Doc and a Google Calendar event. Agents can also perform live web research and return cited sources rather than unsourced summaries.

## Guardrails with an LLM-as-judge on input and output

Safety in AMIGO AI is implemented as two separate model checks around every run. The input screen inspects the user request and any retrieved content for prompt injection attempts, sensitive PII and phishing patterns before the agent is allowed to plan. The output review inspects the agent's draft result for leaked secrets and unsupported claims, and a redaction step strips credentials automatically. This matters because agents with write access to Slack, Gmail and GitHub can do real damage: a single leaked API key in a Slack message or an invented statistic in a Google Doc is a production incident, not a glitch. Treating the judge as a gate — not a suggestion — is the difference between an agent you can leave scheduled overnight and one you have to babysit.

## Deploying the stack on Kubernetes with KEDA autoscaling

AMIGO AI ships as two separate services — a Next.js web app and a worker — each in its own Docker image, deployed to Kubernetes. The worker is the part that scales, because it is the part that consumes the Inngest queue. KEDA watches queue depth and scales the worker between 1 and 5 pods, so an idle night costs one pod and a burst of scheduled agents adds capacity without manual intervention. Around that core the manifests include liveness and readiness probes, rolling updates for zero-downtime deploys, a cleanup CronJob for stale records, and structured JSON logging so container logs are queryable. The web tier stays stateless and can be scaled independently of the workers.

## Choosing between the OpenAI Agents SDK and a planner model

A common question is why the project uses both the OpenAI Agents SDK and Google Gemini. They solve different problems. The Agents SDK provides the execution loop, tool-calling conventions, handoffs and tracing for the agent that actually does the work. Gemini is used as the planning model that converts free-form English into a structured spec — goal, steps, apps, schedule — which is a bounded extraction task rather than an open-ended reasoning one. Keeping planning and execution separate makes each cheaper to test: you can unit-test the planner against fixed prompts and swap either model without rewriting the other half. The same logic applies to integrations: Composio handles OAuth and connector maintenance so the agent code stays focused on decisions.

## Links from the video

- [AMIGO AI code and architecture on GitHub](https://github.com/mueed26/AMIGO-AI)
- [Mir Mueed on LinkedIn](https://www.linkedin.com/in/mirmueed)

## What to take away from this OpenAI Agents build

AMIGO AI is a working reference for the unglamorous half of agent engineering: planning specs, durable queues, guardrails and autoscaled workers. The pattern worth copying is the separation of concerns — Gemini plans, the OpenAI Agents SDK executes, Composio connects, Inngest retries, KEDA scales, and an LLM-as-judge polices both ends of the pipeline. Start by cloning the [AMIGO AI repository](https://github.com/mueed26/AMIGO-AI), run the web and worker services locally with Docker, and add one integration before you add ten. The video breakdown by Mir Mueed on the channel Mir Mueed walks through the scheduled agent, the four parallel runs and the chat-triggered action end to end.

## Questions & answers

**Do I need the OpenAI Agents SDK to build agents that act in real apps?**

No, but it saves substantial work. The SDK supplies the execution loop, tool-calling conventions, handoffs and tracing, which are the parts most teams rewrite badly. AMIGO AI pairs it with Google Gemini for planning and Composio for authenticated integrations, so each layer stays replaceable.

**How does AMIGO AI prevent an agent from leaking secrets or posting false claims?**

It runs an LLM-as-judge on both sides of a run. The input screen blocks prompt injection, sensitive PII and phishing before planning; the output review flags leaked secrets and unsupported claims, and automatic redaction strips credentials from results before they reach Slack, Gmail or a Google Doc.

**Why does the worker scale from 1 to 5 pods instead of running a fixed pool?**

Scheduled agents create bursty load, so a fixed pool is either idle or overloaded. KEDA reads Inngest queue depth and adjusts the worker replica count between 1 and 5, keeping cost low at night while absorbing parallel runs during the day.

**Can agents run on a schedule and also be triggered from chat?**

Yes. A generated agent supports all three trigger modes: scheduled runs on its defined cadence, manual on-demand runs from the dashboard, and chat-based runs where a message triggers a live action. Every execution is recorded in the run history with its step results.