AWS Summit Bangkok 2026 Link to heading
This year I had a chance to speak at AWS Summit Bangkok about Building Multi-Agent Systems on AWS.
If you want to see the slides, they are available on SlideShare: Building Scalable Multi-Agent AI Systems on AWS Cloud Platform.
My starting point was simple: everyone is a builder now. AI tools made it easier to create prototypes, demos, internal tools, experiments, and strange weekend projects. The speed is real. But production is still hard.
Many AI solutions still do not reach production because the first problem is not even the code. The first problem is choosing where to start. There are too many tools. Every new framework looks good. Every IDE looks smart. Every agent platform promises that it can do the work. GitHub is becoming the new Instagram: everyone shows screenshots, demos, and impressive commits, but it is not always clear what is actually running in production.
That is why I moved the talk toward one practical answer: build on AWS.
One Solution: AWS Link to heading
The AWS AI development story is getting much more connected.
For agents, there are Strands Agents. For models, orchestration, knowledge, guardrails, and managed AI features, there is Amazon Bedrock. For developer workflow, there is Kiro IDE. Together they give builders a clear path from idea to working system.
The important part is not only that these tools exist. The important part is that they fit together.
You can build faster because the pieces are connected. You can keep the data inside your environment. You can manage access with the AWS controls your company already understands. You can see cost in one billing place. For many companies this matters more than having the newest framework from last week.
AI development has enough uncertainty already. The platform should remove some of that uncertainty, not add more.
Multi-Agent Systems Link to heading
My first recommendation was:
A team of specialists is better than one generalist.
One big agent with one huge prompt can look attractive at the beginning. It feels simple. But after the system grows, it becomes hard to understand why it made a decision, why it used a tool, or why it ignored an instruction.
Multi-agent systems work better when each agent has a real role:
- different goal
- different tools
- different context
- different success criteria
This is similar to a real team. You do not want five people with the same responsibility. You want one person to own security, one to own deployment, one to own data, one to review code, and one to coordinate the work.
The same is true for AI agents.
One warning: AI is very goal-focused. It can be bad at understanding the difference between the global goal and the personal goal of one agent.
If the global goal is “ship the feature safely”, but one agent only has the personal goal “make tests pass”, it may optimize for the wrong thing. It may remove a test, skip a validation step, or make the smallest local change that hides the real issue.
So every agent needs a narrow goal, but the system still needs a clear global goal.
Tools Beat Prompt Policing Link to heading
My second recommendation was:
API, CLI, and MCP tools are better than “Please do not” and “YOU MUST NOT” instructions.
Agents need to act. If we only give them text instructions, we are asking the model to remember rules and behave perfectly. That is fragile.
If you want an agent to deploy, give it a deployment tool. If you want it to inspect infrastructure, give it a read-only CLI command. If you want it to work with an internal system, expose a small API or MCP server. Even a CLI with a good --help command and a short skill file can be much stronger than a long prompt.
Prompt tuning has value, but it is not a control plane.
The better pattern is:
- give the agent clear tools
- make the tools scoped
- make the tools observable
- make dangerous actions explicit
- let the agent read help and learn the workflow
This is much more reliable than trying to write the perfect sentence in the system prompt and hoping the model follows it forever.
Context Is Not Optional Link to heading
My third recommendation was:
Without knowledge and history, AI starts from scratch each time.
This is one of the biggest gaps in agentic systems today.
A human engineer does not start from zero every morning. They remember why the system is built this way. They remember that the auth layer was changed last year. They remember which RDS instance belongs to which workload. They remember the production incident that caused a weird-looking guardrail.
AI agents usually do not remember any of that unless we build the context layer for them.
That was the main demo in my session: a Slack bot connected to a knowledge layer for AI agents, with context from AWS, GitHub, and Slack.
The idea is practical:
- Are you bored when AI needs to scan the whole AWS cloud just to find the right RDS instance?
- Are you a developer who forgot how authentication was implemented a year ago?
- Are you a head of security who wants to know if a new CVE affects your company?
This is where a knowledge layer becomes useful. It gives agents memory, company context, and a way to answer questions with the environment in mind.
After a year of development, we now have a playground to test this idea. It is not magic. It is still engineering. But it shows what becomes possible when agents have context instead of only a prompt.
Building in Parallel Link to heading
Another point I shared is that AI changes the way we build.
With enough structure, it is possible to build multiple systems in parallel. Not perfectly, and not without review, but faster than before.
One of my hobby projects is a Personal Private Notetaker.
The goal is simple: I want to catch what I promise to people, execute better, and delegate follow-up work to other AI agents. I also do not like that even with a Mac Pro on my desk, I still often need to send my voice to a data center somewhere just to get a transcript back.
For me, local-first AI is not only about privacy. It is about control, latency, and trust. Some workflows should stay close to the machine and close to the person.
Final Takeaways for AI Builders Link to heading
AI creates speed, but speed creates distraction.
So builders need focus. Scope is more important than ever. If one engineer can now generate a huge amount of code, tokens, infrastructure changes, and pull requests, engineering discipline becomes more important, not less.
The basics still win:
- controlled deployments
- clear ownership
- guardrails
- cost monitoring
- observability
- release discipline
Multi-agent systems are powerful, but they can also become the new microservices problem. Do not create too many agents just because it is possible. Create agents when the role, toolset, and goal are different enough to justify a separate specialist.
About the Summit Link to heading
AWS Summit Bangkok itself was good. It was also crowded. There were a lot of people this year, which is a good signal for the local cloud and AI community.
The Developer Lounge was perfect. This year we had new equipment, and that helped a lot. It made the speaker experience smoother and the demos easier to run.
I also noticed more gamification across the summit. Many booths were actual games, and some were built with Kiro. People could add their own features during the summit, which made the experience more fun and more hands-on.
That is probably the right direction. AI tools are easier to understand when people can build something with them, not only watch slides about them.
I will add photos from the event later when I get them.
For now, the main message is this:
AI builders need less noise, better tools, more context, and stronger engineering discipline. AWS gives a solid place to put those pieces together.