Last month, I gave a talk at JS Belgrade about OpenAI’s Agent Builder.
The pitch:
OpenAI’s no-code agent builder creates and deploys AI agents into production with just a few clicks.
The reality? It’s messier than the announcement suggested, but there’s something real here.
The Starting Position
Building AI agents has been mildly frustrating. Write prompts, chain tool calls, handle errors or build UIs - all from scratch or use third-party tools to scramble an AI agent.
Last week, I embedded my Wardley Mapping principles directly into my AI development workflow.
The experiment worked - but not how I expected. It revealed two gaps I hadn’t fully appreciated before:
How can I influence engineering decisions with agent rules/steering documents?
Where is this going to evolve?
The Problem I Was Trying to Solve
I’ve been mapping landscapes for years, but there’s always been this frustrating disconnect. I’d create these detailed maps showing how components evolve, identify strategic opportunities, then watch and participate in a team effort to build features that completely ignore the landscape context.
Recently, I have been playing a lot with AWS S3 Batch Operations. The service is amazing for processing large amounts of data in parallel. The only downside is that it is not very well documented and there are a few steps to do before you can start processing your data.
Sometimes I prefer a minimum effective dose of a post, so here is an example of creating an AWS S3 Batch Operations job using the AWS SDK for JavaScript (v3) in TypeScript:
After a long time, I decided to come back and start writing again. One of the easy things to start writing about is what I’ve been working on lately with AWS,