DEV Community: Patrick Bichiou

From Architect to Strategist: What My 7th AWS Certification Taught Me About Balancing Business and Tech

Patrick Bichiou — Mon, 12 Oct 2026 15:12:12 +0000

Last Friday I passed the AWS Certified AI Business Strategist exam, my 7th AWS certification.

This one is different from the others. It’s the first AWS certification without a technical focus. After six technical certifications, it was a real change of perspective.

A different kind of question

In my previous exams, the goal was usually to find the best technical solution. This time, the question was different: what is the best business decision? And that is not always the best technical one. The most elegant architecture is not automatically the right choice if it doesn’t fit the business case, the budget, or the organization’s risk appetite. Weighing these trade-offs was new for me, and I found it fascinating.

ROI and Responsible AI

Two topics stood out for me: return on investment and Responsible AI. Both force you to look beyond what is technically possible. Does an AI use case create measurable value? And can it be built and operated in a way that is fair, transparent, and trustworthy? These are questions every builder should be able to discuss, not just business leaders.

How I prepared

I relied on the official AWS exam guide. It clearly lays out the domains and tasks covered, which makes it a solid starting point for structuring your preparation.

What I take with me

I expect this certification to help me find a good middle ground between business and technical decisions. Many AI projects succeed or fail at exactly this intersection, and being able to speak both languages makes collaboration easier.

If you’re a technical builder wondering whether a non-technical certification is worth it: give it a try. It might change how you look at the solutions you build.

AI Agents as Team Members: Running Them on AWS and Bringing Them into Teams or Slack

Patrick Bichiou — Mon, 12 Oct 2026 15:11:38 +0000

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?

Amazon Q in Practice: How AI Is Transforming My AWS Workflow Between the Console and VS Code

Patrick Bichiou — Sun, 22 Mar 2026 13:41:29 +0000

As an AWS enthusiast, software architect, and developer, I’m deeply involved with tooling. For some time now, my focus has been particularly on AI tools—not only as a support for software development, but also from the perspective of engineering and process optimization. Whether in a professional context or in personal projects, AI has become indispensable to me.
I have always viewed AI tools as instruments that can make our lives easier. Since 2026, I have been an AWS Community Builder in the “Serverless” category, as this is where my developer’s heart lies and most of my projects are built on AWS serverless services. However, this article is less about serverless itself and more about dev tools—specifically Amazon Q, both in the IDE (VS Code) and in the AWS Management Console.

What is Amazon Q?

Amazon Q is an AI assistant that can be used both in the IDE and in the AWS Management Console. In addition, Amazon Q Business is a version that can be integrated with various business tools (such as SharePoint) to streamline processes and aggregate information from different systems.

In this article, however, I will focus on Amazon Q as a development and engineering tool. As with all AI tools, the following applies: Amazon Q can provide support, but the responsibility always remains with the developer.

Amazon Q in the AWS Management Console

In my opinion, Amazon Q in the AWS Management Console is primarily aimed at solution architects and technically savvy users.
One particularly interesting feature is the ability to record manual steps and generate CLI commands, SDK code, CDK applications, or CloudFormation templates from them. This allows you to track actions that were initially performed manually and then automate them.
This is especially useful if you initially feel more comfortable setting up infrastructure manually but want to make it reproducible later on.

The console chat can also be a good starting point for automation. I’ve personally used the management console’s context to generate scripts that allow me to automatically manage existing resources.

Amazon Q in the IDE (VS Code)

Within the IDE, Amazon Q can be used in both chat mode and inline. It also offers helpful shortcuts, such as for refactoring or documenting code snippets and entire components.
Chat mode makes it very easy to interact with Amazon Q, for example, to develop new components iteratively. You can think of it, to some extent, as collaborating with a colleague. This quickly brings to mind pair programming: What used to take place exclusively between multiple developers can now be supplemented by tools like Amazon Q—or even implemented entirely with them.
At the same time, Amazon Q can also be used in a traditional team setting to obtain an additional, well-founded opinion. Especially in the context of AWS projects, the results are often very convincing.

Lessons Learned

Amazon Q in the AWS Management Console is a huge help, especially for those new to AWS, but it can also serve as a starting point for automation. In some services, you can record click paths and derive CLI commands directly from them. This allows you to quickly automate a workflow that was previously performed manually.
The chat feature is also very useful here. I’ve already used it to generate specific CLI commands that subsequently served as the basis for automation.
Within the IDE, Amazon Q really shines in the context of AWS projects. This clearly highlights where the tool’s focus lies. Even though other tools may offer a wider selection of models or be stronger for more general use cases, Amazon Q can absolutely hold its own in the AWS environment. This strength is particularly evident in serverless projects—especially with AWS SAM.

Conclusion

Amazon Q is a powerful tool in both the console and the IDE, offering different strengths depending on the environment. In the IDE, it supports developers directly during the coding process, while in the AWS Management Console, it is better suited for architectural tasks and operational activities.
If you want to take it a step further and generate applications directly based on specifications, Kiro is also worth checking out.

What has been your experience with Amazon Q so far? What do your workflows look like when you use Amazon Q?

Feel free to share your thoughts in the comments—and stay tuned for more content on serverless computing and software development.