From chatbot to colleague
The most useful AI agent on a team is not the smartest one. It is the one that shows up where the team already works, knows its job, and says "I don't know" when it should.
Like many teams, we started with AI as a side tab: someone opens a chat window, pastes context, copies the answer back. It helped individuals. It did not help the team.
So we changed the question. Instead of "which model should we use?", we asked: "what would it take to hire an agent?" A real team member has a role, a seat in the team channel, access to the tools it needs and nothing more, and someone it reports to. This article walks through how we run such agents on AWS and bring them into Teams or Slack, where people already spend their day.
Microsoft calls organizations built around this human-agent model "Frontier Firms". You don't need a transformation program to start. You need one agent, one role, and one channel.
What makes an agent a team member
An agent becomes a team member when you can describe it the same way you would describe a new hire. We write a short "job description" for every agent before we write a single line of code.
| Attribute | Human colleague | AI agent |
|---|---|---|
| Role | Job title and scope | System prompt with a clear mission and explicit non-goals |
| Onboarding | Docs, wikis, shadowing | Knowledge base with product docs, specs, past decisions |
| Access | Accounts and permissions | IAM role and tool list, least privilege |
| Workplace | Team channels and chats | Chat app in the channels where it is needed |
| Manager | Team lead | Named human owner who reviews its work |
| Performance review | Feedback and 1:1s | Traces, evaluations, user feedback |
Three rules follow from this. First, one agent, one role: a "do everything" agent is as hard to trust as a colleague with no job description. Second, the agent's boundaries are written down, including what it must hand back to a human. Third, every agent has a human owner who is accountable for its output, just like a team lead is for a junior colleague.
Architecture: a serverless seat on AWS
The chat platform is only the front door. Everything the agent knows and does runs in our own AWS account, under our IAM policies and our logging.
[embedded content: Agent architecture · Teams to AWS and back]
A message travels down the right side, waits briefly in SQS, and the worker answers back up the left side once the agent is done.
- Amazon Bedrock AgentCore Runtime hosts the agent with session isolation, so each chat conversation keeps its own context. It is framework-agnostic: we can use Strands Agents, LangGraph or plain code.
- Amazon Bedrock Knowledge Bases is the agent's onboarding binder: product docs, specs and past decisions, retrieved with sources.
- AgentCore Gateway exposes internal APIs as MCP tools. Each agent sees only the tools its role needs.
- AgentCore Memory keeps short-term conversation context and long-term facts, such as a team's preferred terminology.
- Amazon Bedrock Guardrails blocks topics outside the role and filters sensitive data before it reaches the channel.
- API Gateway, Lambda and SQS form the thin, cheap glue between the chat platform and the agent. No servers, no idle cost.
AWS services for each part of the job
Amazon Bedrock is the core, but a team-member agent needs more than a model. This is the toolbox we draw from, with the alternatives we weighed.
| Building block | AWS service we use | Alternatives on AWS |
|---|---|---|
| Foundation model | Amazon Bedrock (Anthropic Claude, Amazon Nova) | Amazon SageMaker AI for self-hosted or fine-tuned models |
| Agent runtime | Amazon Bedrock AgentCore Runtime | Amazon Bedrock Agents (managed, less flexible); AWS Lambda for simple agents |
| Agent framework | Strands Agents SDK | LangGraph, CrewAI, or custom code on AgentCore |
| Knowledge and grounding | Amazon Bedrock Knowledge Bases on Amazon S3 | Amazon OpenSearch Serverless or Amazon Kendra as the retriever |
| Tools and integrations | AgentCore Gateway (MCP), AWS Lambda | Action groups in Bedrock Agents; AWS Step Functions for long workflows |
| Memory | AgentCore Memory | Amazon DynamoDB for custom session state |
| Identity and access | AgentCore Identity, AWS IAM, AWS Secrets Manager | Amazon Cognito as the identity bridge to the chat platform |
| Safety | Amazon Bedrock Guardrails | Custom checks in the worker Lambda |
| Chat integration glue | Amazon API Gateway, AWS Lambda, Amazon SQS | Amazon EventBridge for fan-out to several agents |
| Observability and cost | AgentCore Observability, Amazon CloudWatch, AWS Cost Explorer | AWS X-Ray; cost allocation tags per agent |
| Evaluation | Amazon Bedrock model evaluation | Custom test sets run in CI |
Start small: Bedrock, one Knowledge Base, AgentCore Runtime and the API Gateway glue are enough for a first agent. Memory, Gateway tools and evaluations come as the role grows.
Giving the agent a seat in Teams or Slack
The chat platform is the agent's desk, not its brain. Whether your team lives in Microsoft Teams or Slack, the pattern is the same: the platform delivers messages, and the agent on AWS does the thinking.
What changes when an agent sits in the team channel instead of a separate chat tool:
- It works in context. The agent sees the question where it was asked, next to the discussion that led to it. Nobody has to copy and paste background into another window.
- Its work is visible. Answers land in a shared channel, so colleagues learn from them, correct them, and build on them, just as they would with a human teammate.
- It is addressed like a colleague. People @mention the agent, reply in threads, and react to its answers. No new tool to learn, no new habit to build.
- Handovers feel natural. When the agent reaches the edge of its role, it tags its human owner in the same thread. The conversation simply continues with a person.
- The platform is swappable. Because the agent lives on AWS and the chat platform is only a thin connector, the same agent can serve a Teams channel and a Slack workspace at the same time.
One principle matters more than any integration detail: the agent acts with the permissions of the person asking, not with broader rights of its own. A colleague who can't see a document shouldn't get its contents through the agent.
The agent we "hired"
Our first hire took on a job every product team knows: answering the same product questions again and again.
The virtual Senior Product Manager. Product questions reach our team every day: from sales, from support, from customers. Many of them are answered in documentation that already exists. We gave the agent a Senior Product Manager role, grounded it in real product documentation, and told it what it must not do: commit to roadmap dates, quote prices, or promise features. In the team channel, a colleague mentions the agent in a channel, asks "Does the product support 50fps proxies for live sports?", and gets an answer with the source it used. If the agent is unsure, it says so and tags the human PM.
What made it work: a narrow mission, grounded knowledge, a clear escalation path to a named human, and a home in a team channel rather than in someone's private browser tab.
Lessons learned
The technology was the easy part. Making people trust a new colleague took longer.
- Show the sources. Answers with a link to the document they came from get adopted. Answers without one get double-checked, and then ignored.
- Make "I don't know" a feature. We explicitly reward the agent for escalating. One confidently wrong answer costs more trust than ten handovers.
- Least privilege from day one. Each agent has its own IAM role and its own tool list. Read access first; write actions only behind a human confirmation in the chat.
- Trace everything. Every conversation, tool call and model response is traced. When someone asks "why did it say that?", we can answer in minutes.
- Watch cost per conversation, not per token. Long context and chatty tool loops add up. Track the cost of an answered question and set a budget per agent.
- Mind the auth gap. The chat platform and AWS each have their own identity model. Plan early how they connect; it is the part that will surprise you.
- Name the owner in the channel. People accept an agent faster when they know which human stands behind it.
Start with one hire
You don't need an agent platform strategy to begin. Pick one recurring question your team answers every week, write a one-page job description for an agent that answers it, give it a seat in one team channel, and name its human owner.
Run it on AWS with a small serverless backbone, measure whether people actually use it, and grow from there. The goal is not to replace colleagues. It is to give every colleague a teammate who never gets tired of the hundredth "quick question".
I'd love to hear how you are bringing agents into your teams. What role would your first AI hire have?
Top comments (0)