Product

Meet Your Custom Agent

Generic AI doesn't know your stack, your playbook or your team. A Custom Agent does: name it, teach it, plug in only the tools you allow, and your whole team @mentions the same AI teammate in Slack, with every write going through Auto Mode.

8 min read
Cover Image for Meet Your Custom Agent

Your AI Teammate. Built in 3 Steps, No Code.

It's 10:20 on a Tuesday and someone in #platform asks, again, why the staging deploy is stuck. The person who knows checks three dashboards, finds the pending pod, explains the node-pool quota for the fourth time this month, and goes back to what they were doing forty minutes later. Nobody would call that an incident. It's still most of a morning.

Your best people are buried in work that shouldn't need a human. AI was supposed to fix this, and it hasn't, because generic AI doesn't know your stack, your playbook or your team.

A Custom Agent does. It's an AI teammate with a name, your knowledge, access to the tools you choose, and an @mention your whole team can use.


Why generic AI alone doesn't cut it

You've tried it. Your team has tried it. The work that should take 20 minutes still eats four hours.

01Voice

Not yours

Every reply needs a rewrite to match how your team writes.

02Knowledge

Not your playbook

Your policies and last week’s answer aren’t in the chat, so it guesses.

03Reach

Not your tools

It lives in a browser tab that can’t see AWS, GitHub, Slack or Grafana.

Generic AI isn't missing intelligence. It's missing context.

It doesn't sound like you. Every reply needs a rewrite to match your team's voice. Edit, edit, edit, and by lunchtime you could have written it yourself.

It doesn't know you. Your playbook, your policies, the answer your team gave last week: none of it is in the chat. So it guesses, and you double-check everything.

It can't reach your tools. Your data lives in AWS, GitHub, Slack, Grafana and your databases. The AI lives in a browser tab that can't see any of them. So you copy and paste all day, and the answer is only as good as what you remembered to paste.

The AI isn't dumb. It just has no context, so someone on your team still babysits every reply.

The usual workaround is a pinned prompt: a long block of instructions someone saved last quarter and pastes into new chats. It works for the person who wrote it. The moment a second person uses it, it starts to drift.


A pinned prompt versus a Custom Agent

A Custom Agent is your own AI teammate. It has a name, a personality, your playbook and access to your tools. Your whole team @mentions it in Slack and gets the same voice and the same knowledge every time.

Just a pinned promptA Custom Agent
PersonalityA wall of text pasted last quarter. The next chat forgets it.Set once. Every reply, for every teammate, sounds like you.
KnowledgeYou paste the same playbook into every conversation.Your docs, policies and runbooks loaded once. It just knows.
ToolsLives in a tab. Can't see AWS, GitHub, Slack or your dashboards.Reaches AWS, GitHub, Slack, Grafana and your databases, only what you allow.
Team"My prompt" versus "your prompt": five teammates, five different bots.Five teammates @mention the same agent. Same answer, every time.

The deeper difference is ownership. A pinned prompt belongs to whoever pasted it, so knowledge stays personal. A Custom Agent belongs to the team, so a correction one person makes is there for everyone the next day.


How it works

One rule when we built this: if setup took more than three steps, we'd cut one. It never came to that.

01Name it

Name and role

A name your team will recognize and its job in one sentence.

02Teach it

Tone and rules

How it talks, the do’s and don’ts, and your docs and playbooks.

03Plug it in

Tools

Pick exactly which systems it can reach, and nothing else.

04Use it

@mention

Drop it into a channel. The whole team asks the same agent.

Three setup steps, then it works where your team already talks.

1. Name it. What should it be called, and what is it here to do? Pick a name your team will recognize and write its job in one sentence.

2. Teach it. Tell it how to talk: friendly, formal, short and direct. Add the do's and don'ts. Drop in your style guide, FAQ or playbook so it has the same context your team does.

3. Plug it in. Pick which tools it can reach: AWS, GitHub, Slack, Grafana, your databases. You decide exactly what it sees. Then drop it into a channel and start working.

You don't have to fill in forms if you'd rather not. Describe what you need in plain English and CloudThinker sets it up for you.


Building one, end to end

Here's an illustrative build of the agent that would have saved that Tuesday morning.

Name it. @on-call, with the job: "Answer questions about why something in staging or production isn't healthy, with evidence, in plain language."

Teach it. A few lines of rules do most of the work:

"Lead with the answer, then the evidence. Link the dashboard or log line you used. If you're not sure, say what you checked and what you'd check next. Never suggest deleting a namespace or a PVC."

Then attach the two documents people keep asking about: the deploy runbook and the page that explains node-pool quotas.

Plug it in. Read access to the staging and production AWS accounts and the Kubernetes clusters, Grafana for metrics, and the #platform channel in Slack. Nothing with write access.

Use it. The next time someone asks, it looks like this:

"@on-call why is the staging deploy of checkout-api stuck?"

A useful answer starts from the possible readings, not a guess. A stuck deploy is usually one of three things: the new pods can't be scheduled, they're scheduled but failing to start, or they start but fail the readiness probe. Each one leaves a different trace. Pending pods with a FailedScheduling event point at capacity or quota. CrashLoopBackOff or ImagePullBackOff points at the image or config. Running pods that never go ready point at the probe or a dependency. The agent checks the pod status and events, finds FailedScheduling: Insufficient cpu, sees the node group at its configured maximum, and answers in the thread with the event, the node-group limit and the runbook section on raising it.

Correct it once. Someone replies: "For staging we don't raise the limit, we scale down the preview environments first." That's now part of what @on-call knows. The next person who asks gets that answer, from the first message.


And it only gets smarter

What makes it feel like a teammate and not a tool is that it learns. Every conversation, every new doc and every correction makes it sharper.

01Memory

It remembers

Corrections like “we don’t do it that way” become part of what it knows.

02Skills

It picks up more

Add a doc, a tool or a playbook and it starts using them. No retraining.

03Use

It sharpens

Patterns in how your team replies become how it replies.

What changes between week one and month three.
  • It remembers. Every conversation, every correction, every "we don't actually do it that way" becomes part of its memory. Next time, it just knows.
  • It picks up new skills. Add a new doc, plug in a new tool or share a new playbook, and your agent learns to use them. No retraining, no rebuild.
  • It gets better with use. The more your team works with it, the sharper it gets. Patterns it spots in your replies become how it replies tomorrow.

The agent you set up today knows your team a little. In three months, it'll know them better than the new hire.


What it's allowed to do

An agent that can reach your tools needs clear limits on what it changes. Custom Agents act under your workspace's Auto Mode setting, which has two levels:

  • Manual. You approve write actions yourself. Per-tool permissions decide what runs freely, what needs approval and what never runs, so a restart, a ticket or a config change can wait for a named person to approve it in the thread.
  • Auto. A safety check evaluates every write before it runs. Writes that match the goal and scope you asked for go ahead; anything outside that scope pauses for approval, destructive actions escalate, and prohibited ones are denied.

The setting covers the whole workspace, and you can switch it from the chat prompt box at any time. The connections you attach set the outer limit too: an agent only reaches what you've connected to it, and one given read-only credentials can't write, whatever the mode.


What teams build

Four example agents, the same idea each time: the busy work shrinks and people get their afternoons back.

TeamAgentWhat changesWhat it does
DevOps@on-callFaster first answerPulls AWS metrics, scans the logs, finds the broken pod, and posts the answer in Slack before the incident channel fills up.
Engineering@code-reviewerShorter review queueReviews every PR against your team's style guide and flags real issues, so the senior reviewer only sees what matters.
Support@first-replyFaster first replyReads the customer message in Slack or Teams, drafts a reply in your team's voice, and waits for a human to send it with one click.
FinOps@cost-watchMonthly → dailyWatches AWS, GCP and Azure spend every day, flags odd spikes in Slack, and tells you exactly which service grew.

The pattern is simple: the agent handles the busy work, your team handles the judgment calls.

It plugs into what you already use: AWS, GCP, Azure, Kubernetes, GitHub, GitLab, Slack, Teams, Grafana, Datadog and a lot more. Don't see your tool? You can connect it yourself in a few clicks.


Getting started

1. Pick the question your team answers most often. The one that interrupts someone senior three times a week is a good first agent.

2. Describe the agent in plain English.

"Create an agent called @on-call for the #platform channel. It answers questions about unhealthy deploys in staging and production, leads with the answer and links its evidence. Give it read-only access to our AWS accounts, Kubernetes clusters and Grafana. Manual mode, propose only, change nothing."

3. Teach it the first correction on day one.

"@on-call, for staging we never raise node-group limits. Suggest scaling down preview environments first, and link the runbook section."

New use case? Spin up a new agent. No new tool and no new subscription, just a new teammate. A release agent this sprint, a security agent the next. Your bill doesn't grow with them.

Custom Agents are live in every CloudThinker workspace today. Free to start, no credit card, no code. Build one before your next standup.


Related reading

Start your free trial or book a demo to build your first Custom Agent today.

customagentsaiagentsagenticainocodedevopscloudthinker