AG-UI is quickly becoming the standard protocol for how rich agentic experiences are expressed within user interfaces.

How AG-UI Enables Rich Agentic AI Experiences

Something subtle is happening in AI right now.


Agents are starting to act less like black boxes and more like collaborators — pausing, reasoning, asking questions, waiting for your input. That change isn’t just the result of better models; it’s the product of better infrastructure.

Behind the scenes, a small but important protocol called AG-UI is quietly redefining how agents talk to people. It’s the difference between a chatbot that dumps an answer and one that feels alive — responsive, tentative, occasionally uncertain, but engaged in a process with you.

The Shift From Responses to Relationships

For decades, software had a rhythm: you ask, it answers.
REST, GraphQL, JSON — all of them built around the same simple dance of request and response.

Agentic systems don’t behave that way. They think out loud. They can take several paths, change their mind, or reach out to other agents or tools mid-conversation. They don’t just give results; they create them in real time.

The old protocols weren’t built for that kind of dialogue. You can fake it with WebSockets and custom event wiring, but it’s fragile and inconsistent. Every developer reinvents the wheel, and every user experience feels a little different — sometimes sluggish, sometimes magical, sometimes broken.

AG-UI steps in as a universal translator between the agent’s internal logic and the human’s visual or conversational interface. It’s a standard event stream that carries not just the answer but the process — the state updates, tool calls, interruptions, and little moments of “thinking” that make interaction feel collaborative.

To understand where AG-UI fits, it helps to know the rest of the stack forming around it.

MCP (Model Context Protocol) gave agents the ability to use tools and external data.

A2A (Agent-to-Agent Protocol) taught them to coordinate with each other.

AG-UI gives them a way to communicate with us.

Together, those three protocols form a triangle — cognition, collaboration, and communication. They’re what turns a model into a system and a system into something that actually feels intelligent.

The Interface Layer That Changes Everything

What makes AG-UI special isn’t its syntax; it’s its philosophy. It assumes that interaction with intelligence is ongoing, not transactional. That the user should see what’s happening — even mid-thought — and that the agent should be able to listen back.

That might sound small, but it changes how we design entire products.
An interface built on AG-UI doesn’t just wait for output; it reacts to a stream of intent and state. You can visualize progress, guide decisions, or jump in when something looks off.

In other words, it turns AI from a tool you query into a colleague you collaborate with.

For executives looking past the hype curve, this matters because it signals the next layer of stability. AI development is moving from one-off hacks toward standardized communication models.

Just like HTTP made the web interoperable, AG-UI is making agentic applications composable.
It gives product teams a predictable way to connect reasoning to experience. It makes interfaces trustworthy — debuggable, observable, and explainable.

And that’s what enterprise adoption always comes down to: not how smart the system is, but how clearly it shows its work.

There’s a small irony in all of this: the more standardized AG-UI becomes, the more human agents start to feel. They gesture toward uncertainty, reveal their steps, accept interruptions, and learn to converse with rhythm instead of dumping output.

It’s not “emotion.” It’s good architecture.
And like most good architecture, you barely notice it when it works.

You can already see AG-UI sneaking into early frameworks — LangGraph, CopilotKit, CrewAI, Pydantic AI. The big clouds are circling too. These standards always start in the corners and then quietly become the backbone of everything.

There’s still friction ahead: performance, interoperability, versioning. But the direction is clear. We’re heading toward a web of agents that can reason, collaborate, and communicate — in one continuous loop.

And when that loop finally clicks, it won’t feel like AI anymore.
It’ll just feel like good software again.

How to build credible agentic AI: design memory, standardize tools, coordinate multi-agent teams, and govern quality with tracing and evals.

John Salvie - Building AI-Enabled Systems That Think, Remember, and Collaborate

AI has moved from experiment to essential in just a few years. Large language models (LLMs) like GPT and Claude are now woven into the tools we use every day.

The first wave was about what these models could do: generate content, summarize information, answer questions. The second wave is about how we design systems around them — how we build AI that is reliable, accountable, and integrated with real business processes.

This is the age of agentic AI. Instead of isolated chatbots, we’re seeing networks of intelligent agents: software entities that remember, plan, act, and even collaborate with each other and with humans to get complex work done.

The implications are profound. But like any transformation, the challenge is as much about architecture and governance as it is about algorithms.

Without memory, an AI system is stuck in the moment. It can respond, but it can’t adapt or learn. Modern agent design requires multiple layers of memory:

Short-term context – the immediate conversation or task at hand.

Persistent knowledge – facts about users, systems, and policies.

Selective recall – deciding what matters most at the right time.

The design challenge isn’t just about the storage of memory data, but also mostly around choosing what to surface and when. Too much information clutters outputs and drives up cost. Too little, and the system loses continuity.

The most advanced agents now use semantic recall — retrieving memories based on meaning, not just recency — similar to how humans recall relevant experiences when solving a problem.

New reasoning models go beyond text generation. They break problems down step-by-step, showing their work along the way. This unlocks use cases like:

Complex planning across multiple workflows.

Instead of blindly producing output, these systems think through decisions and can explain their reasoning.

Today’s static agents are limited: fixed prompts, fixed tools, fixed behaviors. Real work is dynamic. Next-generation agents are beginning to switch models based on task complexity, adjust tone and style in real time, and load and unload tools as situations change.

This flexibility adds complexity. Teams must plan for security, permissions, and testing across many possible configurations.

Fragmentation is a major barrier to scaling AI. The Model Context Protocol (MCP) is emerging as a common way to connect agents and tools. MCP makes it easier for different systems to work together. This speeds development and creates a foundation for broader ecosystems, where agents from different companies can collaborate securely. In addition to MCP, we’re actively helping customers complementary protocols, like agent-to-agent (A2A) and agent network protocol (ANP).

Retrieval-Augmented Generation (RAG) started off as one of the more common patterns for bringing enterprise data into AI systems. Newer agentic architectures are exploring non-RAG approaches that may be either simpler, or more sophisticated. Some of these include:

Agentic RAG – agents call domain-specific tools instead of just retrieving text.

Reasoning-Augmented Generation (ReAG) – models preprocess and structure data before retrieval.

Full context loading – with massive context windows, entire datasets can be loaded directly.

The right strategy depends on your problem space. Start simple, then layer in complexity as needed.

The future isn’t a single all-knowing agent. It’s a team of specialized agents, each with defined roles. For example, instead of having a Sales agent that does “everything sales”, a company may instead define:

A discovery agent handles communication with the customer

An architect agent that generates a solution brief

An estimation agent that creates a project estimate

New standards like A2A (Agent-to-Agent) are emerging to support collaboration between these systems, even across company boundaries.

Building these digital teams requires the same care as designing human ones — clear roles, rules of engagement, and oversight.

Observing and Measuring Agent Performance

As autonomy increases, visibility becomes critical.
Two practices are essential:

Tracing every step, tool call, and decision for accountability.

Continuous evaluation to measure quality, reduce hallucinations, and track performance over time.

This is the AI equivalent of DevOps: monitoring and improving systems continuously.

For organizations exploring agentic AI, preparation should be tactical and deliberate:

Create architectural standards
Define how agents will be built, secured, and integrated — similar to how you design API or security standards.

Develop an Agentic AI design guide
Document patterns for creating new agents, including naming conventions, memory design, and tool selection.

Define measurement and governance
Decide how you’ll trace behavior, run evaluations, and manage performance over time.

Pilot with clear boundaries
Start with a focused use case, test extensively, and scale once the system is predictable and explainable.

Treat agents like team members
Assign roles and permissions, set rules for collaboration, and review performance regularly.

Agentic AI represents a fundamental shift in how organizations operate. The next generation of systems won’t just respond to commands — they’ll plan, adapt, and collaborate. By focusing on memory, adaptability, standardization, and governance, businesses can move beyond experiments and build systems that are both powerful and trustworthy. The future of AI isn’t just smarter models. It’s smarter systems. Now is the time to start designing them.

Building AI-Enabled Systems That Think, Remember, and Collaborate

If you’ve ever spent a week navigating the hallways of The Venetian or Mandalay Bay during AWS re:Invent, you know just how easy it is to get overwhelmed. There’s the constant buzz—thousands of cloud practitioners, founders, and big-name vendors, all jockeying for attention, promising a future where the friction of scaling technology disappears at the click of a button. The scope is massive, the hype is unavoidable, and the announcements come at a breakneck pace. For us at Allata, as cloud and technology strategists, this year’s event was a chance to filter the noise, keep a conversational and realistic perspective, and find a few gems that point the way to what’s next. Our guiding ethos? “Now go build”—not just more of the same, but better, more sustainable, and more imaginative solutions.

The Data Layers Are Becoming Truly Foundational

Let’s start with what’s undeniable: Data is everywhere, and it’s now the heart of everything from analytics to AI-driven decision-making. AWS’s continued push to integrate analytics directly at the point of data captured—what many are calling a zero-ETL future—felt more like a promise than a pipe dream this year.

Aurora DSQL: Another highlight was Aurora DSQL, a distributed SQL flavor meant to play nicely with low-latency reads and writes at scale. For practitioners who struggle to keep transactional and analytical workloads under one roof, Aurora DSQL suggests a future where you don’t have to compromise. Your transactional database can begin to power real-time insights, rather than waiting on some brittle ETL pipeline.

S3 Metadata: One of the more meaningful enhancements was the introduction of automatic metadata capture for objects in S3, backed by managed Apache Iceberg tables. Translation: simpler curation and discovery for large datasets, less time wasted in painful ETL jobs, and more time spent running queries against data that’s actually accessible. While there’s still some refinement needed, it’s an exciting step. Stop wrangling data and start experimenting with it—that’s the spirit of zero-ETL.

SageMaker feels like it’s truly cementing its position as the go-to, all-in-one AI hub in AWS’s ecosystem. Whether you’re dabbling in machine learning for the first time or orchestrating large-scale model training for complex LLMs, SageMaker’s ongoing expansions—from improved training speeds to better model deployment options—make it feel like the center of gravity for AI on AWS. While not every enterprise needs full-blown generative AI right now, it’s clear that AWS wants SageMaker to be the first stop on your journey, no matter how modest or ambitious your ML goals.

Architecture Patterns: MACH, Event-Driven, and Multi-Agent

If re:Invent 2024 taught us anything, it’s that there’s no single architecture pattern to rule them all. Instead, it’s about pick-and-choose, assemble, and evolve.

MACH Architectures: MACH (Microservices, API-first, Cloud-native, and Headless) continues to gain steam, showing up in conversation after conversation. The flexible, decoupled, and composable nature of MACH fits right in with zero-ETL pipelines and AI-first strategies. Modern enterprises want the freedom to pivot quickly—MACH approaches let you innovate without being handcuffed to legacy monoliths.

Event-Driven Architectures (EDAs): EDAs are no longer fringe. They’re front and center. With sessions like “Generative AI architecture patterns in production” and “Event-driven architectures at scale,” AWS pushed the narrative that loosely coupled, asynchronous systems are the future. Services like MSK and Kinesis point the way to a world where real-time event streams feed directly into analytics, ML models, and business logic—all without waiting for a scheduled ETL job.

Task Orchestration & Multi-Agent Collaboration: On the AI side, multi-agent systems and more advanced orchestration tools are emerging. Whether it’s programmatic flows governed by Step Functions or semantic orchestration guided by AI agents, the takeaway is that complex workflows no longer need to be chained together by brittle scripts and manual interventions. Instead, we can use intelligent agents to collaborate, handle complexity, and scale up our decision-making processes. This shift also ties into the concept of GraphRAG (Graph + Retrieval Augmented Generation), LLM validation tools, and orchestration strategies. The key trend: Let’s get smarter and more strategic about how services talk to each other, rather than just wiring everything together in one big spaghetti mess.

Modern Collaboration and Planning: Miro Steps In

In a world defined by remote teams and distributed architectures, it’s not just about the code anymore. Collaboration, brainstorming, and planning tools are finding new niches within the AWS ecosystem. Tools like Miro, with its diagramming, cost calculator integrations, and AWS MAP templates, are becoming vital parts of the workflow. The idea of “diagrams to code” or “AWS accounts to diagrams” isn’t just a neat demo; it’s a way to break down silos between technical, product, and strategic teams. Everyone can visually reason about the architecture, and in turn, the architecture can produce code that’s faithful to the team’s shared understanding. Miro’s presence at re:Invent showed that as complexity grows, the tools that let us visualize, share, and iterate become just as important as the code that runs behind the scenes.

Let’s talk about the expo floor. Sure, AWS dominates the headlines, but part of the fun of re:Invent is wandering the expo hall and bumping into innovative startups and established players pushing the envelope.

Harness: A platform focused on modern CI/CD and feature flagging, making continuous delivery more approachable.

Port: With an emphasis on environment management and infrastructure governance, Port is riding the wave of internal developer platforms.

Orb (fine-grained payments): Interesting solutions around payment models, usage tracking, and monetization mechanics.

Flox: A novel take on open-source software management to streamline dev workflows.

WorkOS: Making enterprise authentication and SaaS integrations simpler.

These are just a handful of the many companies working hard to stand out from the crowd. What’s special here is the sense of camaraderie and cross-pollination. It’s fun to discover tools that might solve that one pain point you’ve been wrestling with for months.

Speaking of fun, it’s not all about the tech. There’s something to be said for grabbing a coffee with a colleague, striking up a conversation with a stranger about their approach to event-driven frontends, and later watching Weezer play at the rePlay party. That’s the intangible value of re:Invent—the serendipity, the unexpected connections, and a soundtrack that reminds you that tech isn’t just about code and data centers; it’s about people and shared experiences.

Engaging as a Professional Services Firm: Exploring, Not Just Showcasing

At Allata, we’ve come to realize that simply having a booth at re:Invent might look good on paper, but it doesn’t always produce the most meaningful value. It’s expensive, it’s loud, and it’s hard to differentiate yourself when everyone’s jostling for attention. Instead, we prefer to dive into the sessions, sit next to customers and colleagues, and “be in it” rather than just “be at it.” Attending re:Invent as a participant—actively exploring new services, patterns, and conversations—gives us a deeper, more nuanced understanding of the trends and tools that matter.

This approach aligns with our guiding philosophy: Don’t just coast along with the status quo. Embrace new architectures like MACH or event-driven approaches, try out new features like S3 Metadata or Aurora DSQL, and resist the urge to keep doing what you’ve always done just because it’s comfortable. Innovation requires a willingness to pivot, to consider intangible ROI, and to experiment without a guaranteed payoff. That’s exactly what the spirit of re:Invent encourages.

As we pack up and head home, the message from re:Invent is clear: The landscape is moving fast, and waiting on the sidelines isn’t an option. Data-driven decisions, zero-ETL architectures, AI at the core, event-driven patterns, and the evolving toolkit around orchestration and collaboration are changing the playbook. Don’t just add these capabilities as afterthoughts—integrate them into your DNA.

In other words, now go build. Build to learn, build to adapt, and build to meet customers where they are. You might not get everything right on the first try, but that’s part of the journey. With a little guidance—and a whole lot of curiosity—you’ll be ready for the next re:Invent and beyond.

Generative AI architecture patterns in production for SMBs (SMB304):
https://www.youtube.com/watch?v=vD2lxJzfwcM

Designing Asynchronous Frontends:
https://www.youtube.com/watch?v=uqu7D6q1h34
GitHub Patterns: https://github.com/aws-samples/eventdriven-frontend-patterns/tree/main/flight-status

Event-driven architectures at scale: Manage millions of events (API307):
https://www.youtube.com/watch?v=dy7UXS7ur14

Implementing security best practices for serverless applications (SVS324):
https://www.youtube.com/watch?v=jYbfQ07Z7rM

Best practices for serverless developers (SVS401)
https://www.youtube.com/watch?v=5wokwEtddtc

If you’re like many business and technology leaders I work with, you’ve probably felt the pain of juggling multiple services for data, analytics, and AI. Sure, you might already tap into Amazon Redshift for analytics, EMR for big data, Glue for data integration, and Athena for on-the-fly queries. Maybe you’ve dabbled with Bedrock to lay the foundation for AI and QuickSight to make sense of it all visually. But if you’re honest, pulling all these capabilities together into a unified experience has been no small feat.

Same Name, New Product
The newly overhauled Amazon SageMaker aims to ease that burden. Traditionally, SageMaker was AWS’s go-to environment for machine learning tasks. Now, it’s stepping up as a more cohesive “studio” that stitches together your data sources, tools, and workloads—without demanding you rip out the pieces you rely on. Think of it as going from a scattered toolbox to a fully equipped workshop where everything’s within arm’s reach.

SageMaker Lakehouse & Zero-ETL:
At the heart of this evolution is the SageMaker Lakehouse, an Iceberg-compliant data store built on S3. It integrates with Amazon Aurora, RDS for MySQL, DynamoDB, and Redshift using a “zero-ETL” approach, so you aren’t stuck handcrafting data pipelines. Bottom line? Your team can spend more time building AI models, analyzing trends, and delivering value—instead of wrestling with ETL workflows.

Better Data Governance & Metadata:
The SageMaker Catalog, evolving out of Amazon Data Zone, automatically generates metadata for your S3 objects and streamlines data discovery. This means everyone—data engineers, analysts, ML scientists—can find what they need faster, with fewer headaches. Good governance and straightforward metadata aren’t just nice-to-haves; they’re fuel for more informed, strategic decision-making.

GenAI to Lower the Barrier:
No matter if you’re querying data, refining a model, or just exploring what’s available, SageMaker now offers Amazon Q, a GenAI-based assistant. Ask it in plain English where to find a specific data set, get code snippets, or troubleshoot a tricky query. This isn’t about dumbing things down; it’s about giving everyone a fair shot at working productively with your data assets—whether they’re seasoned data pros or business stakeholders dipping their toes into the analytics world.

No Forced Migrations or Budget Shock
One of my favorite aspects here is that AWS isn’t asking you to overhaul what’s working. Keep using Redshift, EMR, Glue, Bedrock, and the rest just as you always have. SageMaker simply acts as the connective tissue, offering a common interface without introducing hidden fees or price hikes. That’s huge if you’re trying to modernize on a budget—embrace new capabilities without nasty surprises when the bill shows up.

A Nod to the Bigger Picture
If you’ve been watching the market, you know AWS is catching up to moves by Microsoft Fabric and other players. Databricks pioneered the “lakehouse” concept, and AWS is now taking that vision further, blending analytics, AI, and data management into one environment. This reflects a broader trend: the lines between data analytics and AI are blurring, and platforms are scrambling to meet customers where they already stand.

For companies like Roche and NatWest Group—early adopters of these capabilities—the expected efficiency gains are significant. That’s proof that this isn’t just marketing fluff; the improvements are tangible.

Where to Start
Don’t feel you have to transform your entire operation at once. Begin with a small project—maybe bring Aurora data into the Lakehouse with zero-ETL, or experiment with how metadata in S3 simplifies your next analytics sprint. Once you see results, scale up.

Why This Matters Now
As someone who consults with companies navigating their digital journey, I see a lot of potential here. Organizations want to innovate, but complexity can be a killer. With SageMaker’s new integrated environment, AWS is offering a more direct path from raw data to actionable insight, and from siloed ML experiments to enterprise-grade AI strategies.

In today’s race to stay relevant and drive smarter decisions, having a unified environment that still respects your existing ecosystem is a breath of fresh air. The reimagined Amazon SageMaker could be your springboard to doing more with what you have—faster, and with fewer hurdles.

How Amazon SageMaker’s Next Evolution Simplifies Your Data and AI Stack

AWS announced a series of enhancements to S3 and its database offerings, all geared toward simplifying analytics, AI workloads, and reducing operational complexity. These improvements include automatic metadata generation, integration with Apache Iceberg tables, a new storage layer for tabular data, and advanced database capabilities. Collectively, these features are moving AWS toward a more seamless, zero-ETL future, where enterprises can run analytics and AI directly on operational data with fewer data movement steps.

S3 Metadata and Apache Iceberg Integration:
S3 will now automatically generate metadata as objects are ingested, with that metadata stored in managed Apache Iceberg tables. This approach enables applications to query large datasets more efficiently, reduces the need for manual metadata management, and makes data more readily accessible for inference tasks and sharing with services like Amazon Bedrock. By handling this process automatically, AWS eliminates a common bottleneck in analytics workflows and sets the stage for simpler, more dynamic data environments.

Amazon S3 Tables for Tabular Data:
AWS introduced Amazon S3 Tables, optimized storage explicitly designed for tabular data such as daily transactions, sensor readings, and other row-and-column formats. With S3 Tables, organizations can run analytics and AI workloads on their data without having to transform it extensively or move it across multiple systems. This structure also aligns with zero-ETL efforts, allowing users to streamline the data pipeline and reduce both latency and operational overhead.

Aurora DSQL for Low-Latency, Distributed SQL:
AWS debuted Aurora DSQL, a distributed SQL database engine that scales horizontally, delivers low-latency reads and writes, and remains compatible with PostgreSQL. Aurora DSQL is optimized to run complex queries rapidly, making it suitable for real-time analytics and operational workloads that feed directly into AI models. By offering a highly performant, distributed database solution within Aurora, AWS reduces the complexity of large-scale analytics operations and moves closer to a model where transactional and analytical workloads coexist in a single, integrated environment.

Out-of-the-Box Support for GraphRAG in Bedrock Knowledge Bases:

Developers building Generative AI applications can enable GraphRAG in just a few clicks by specifying their data sources and choosing Amazon Neptune Analytics as their vector store when creating a knowledge base. This will automatically generate and store vector embeddings in Amazon Neptune Analytics, along with a graph representation of entities and their relationships.

Zero-ETL Readiness:
These updates collectively push AWS toward a zero-ETL paradigm, where data can be analyzed and enriched without repeated extraction, transformation, and loading steps. The automated metadata creation, tabular S3 structures, and low-latency distributed SQL capabilities all reduce friction, enabling data engineers, analysts, and data scientists to work more directly with their data. This translates to lower costs, faster insights, and simplified operations as AI and analytics workloads scale.

Prefer a Summary? Here are the key points...

S3 Metadata Generation cuts manual metadata tasks, enabling richer, faster analytics and smooth data exchange.

Amazon S3 Tables for Tabular Data: Provides a new, analytics-friendly storage format that supports zero-ETL workflows.

Aurora DSQL: Scales horizontally, delivers low latency, and is PostgreSQL-compatible, powering near real-time analytics without complex ETL.

Turnkey GraphRAG in Bedrock Knowledge Bases: Developers can now automatically establish representations of entities and their relationships when building knowledge bases.

Zero-ETL Goal: All these features together make it easier to analyze and act on data without the traditional, costly data movement and transformation steps.

AWS Overhauls S3 and Databases to Support AI and Analytics Workloads

It’s the overall experience that signifies complexity

I’m on my flight back from AWS re:Invent, and my mind keeps returning to a central theme that ran through Dr. Werner Vogels’ keynote: Simplexity. The concept—acknowledging that truly scalable, resilient systems require a balance of simplicity and complexity—felt like it hit the sweet spot for many organizations I advise. It resonated with the challenges I see daily in companies aiming to modernize: they know they need to evolve, yet often find themselves tangled in the details of distributed systems, cloud-native infrastructures, and SaaS transformations.

What is Simplexity? It’s the idea that building for the future doesn’t mean chasing simplicity at all costs, nor does it mean stacking complexity without purpose. Instead, it’s about embracing desired complexity—the kind that drives scalability and innovation—while ruthlessly pruning undesired complexity that sneaks in and stalls progress.

Desired vs. Undesired Complexity
Think of desired complexity as the foundational, well-understood elements you need to run large-scale distributed systems. Techniques like fine-grained microservices, event-driven architectures, and partition strategies can be complex under the hood, yet they’re essential for elasticity, fault isolation, and long-term adaptability. These intentional complexities help your business deliver features quickly, handle seasonal spikes, and recover gracefully from failures.

Undesired complexity is what slows you down. It’s codebase bloat, tangled dependencies, and opaque architectures that force teams into firefighting mode. This sort of complexity doesn’t scale; it distracts teams from innovation, throttles feature velocity, and can quietly balloon operational costs.

Spotting Undesired Complexity
Before turning to the tools and patterns that AWS and other industry leaders champion, it’s important to recognize when complexity has gotten the upper hand. Warning signs include slowing feature releases, frequent escalations to resolve issues, and a sense that the code is drifting away from anyone’s full understanding. These signals often show up in “tech-second” industries—organizations where technology supports rather than leads the business. When leaders see these flags, it’s time to take action.

Techniques for Achieving Simplexity
Dr. Vogels emphasized principles that I regularly help my clients adopt:

Model Systems on Business Concepts:
Align your architecture with real-world business domains. When you do this, systems become more intuitive to evolve over time.

Hide Internal Details:
Make sure that external consumers (other services, teams, or business units) interact through well-defined interfaces. This reduces interdependencies and lets you change things behind the scenes without creating ripple effects.

Adopt Cloud-Native Patterns:
Whether it’s embracing serverless, container orchestration, or managed data services, leverage AWS offerings that shift complexity into managed layers of the stack. It’s not about removing complexity, but putting it where it can be better managed.

Failure Isolation & Observability:
Design so that when one part fails, it doesn’t bring down the entire system. Invest in observability—logging, tracing, metrics—so you can quickly diagnose problems. Effective observability makes complexity feel less daunting because you can see exactly what’s happening inside your system.

Break Down Complexity Into Manageable Units:
Techniques like shuffle sharding and partitioning by customer ID aren’t just clever patterns—they’re proven methods to limit the blast radius of failures and keep complexity contained.

Automate the Mundane:
Offload repetitive, non-judgment-based tasks to automation. By integrating CI/CD pipelines, infrastructure-as-code, and automated testing, you push complexity into predictable, repeatable scripts. This frees up human talent to focus on innovation rather than grunt work.

Empowering Teams Through Ownership
None of this sticks without cultural alignment. Smaller, autonomous teams owning their piece of the puzzle can drive both simplicity and resilience. When teams feel agency—control over their technology decisions and the urgency to deliver—they tend to build systems that are intuitive to operate and easier to evolve. Leaders, in turn, should step back enough to let teams run, but keep a foot on the gas, ensuring focus and momentum remain high.

Where to Begin
For executives unsure where to start, the key is not a massive overhaul on day one. Instead:

Identify one friction point, one system, or one domain that’s causing headaches.

Begin chipping away at undesired complexity—perhaps by refactoring a legacy monolith into a few well-defined services, or migrating a high-maintenance database to a fully managed AWS offering.

Engage with your teams and partners who understand distributed systems and SaaS mindsets. Their guidance can prevent you from inadvertently swapping one form of complexity for another.

A Pragmatic Path Forward
Simplexity isn’t about making everything easy—no truly scalable, robust architecture is trivial. It’s about owning the complexity that matters and shedding the rest. By focusing on intentional design, leveraging the capabilities of cloud-native services, and cultivating a culture of ownership and continuous improvement, executives can set their organizations on a path to build systems that evolve gracefully.

AWS re:Invent reminded me that while technology moves quickly, the core principles remain clear. As technology leaders, our role isn’t to eradicate complexity altogether—it’s to harness it. By applying Simplexity, we help our organizations thrive amid change, rather than get bogged down by it.

As someone who has spent over a decade in the tech industry building SaaS applications, I've learned that incorporating "teams" or multi-tenant functionality from the very beginning is crucial. It's a lesson many developers overlook, leading to significant challenges and user frustration down the line.

You might think, "My app is simple and designed for individual users. Do I really need to consider teams right now?" The answer is a resounding yes. Even seemingly straightforward applications, like a bookmark manager, eventually encounter users who want to share access—be it with family members, colleagues, or assistants. Humans are inherently social creatures, and our software needs to reflect that reality.

The Importance of Modeling Human Relationships

When we create software, we're essentially modeling aspects of the real world. If we neglect the concept of human relationships, we introduce a disconnect between how people naturally interact and how they use our applications. This mismatch can lead to user frustration and limit the potential growth of your product.

By incorporating teams functionality from the outset, you align your application with users' expectations and needs. It also saves you from the complex and often painful process of retrofitting this capability later on—a task that can consume significant time and resources.

Choosing the Right Foundation: "Organization" as Your Top-Level Entity

A critical step in building multi-tenant functionality is deciding what to call your top-level entity—the container that represents a group of users and their shared resources. Common terms include "Account," "Team," "Company," "Tenant," and "Workspace." Each has its drawbacks. For example:

Account can be confusing, as users might associate it with their personal login credentials.

Team might not be ideal if you plan to support multiple teams within a larger entity.

Company is too narrow if your users aren't all businesses.

Tenant isn't user-friendly or commonly understood outside technical circles.

Workspace is flexible but might be better suited as a sub-division within a larger group.

I recommend using "Organization" as your top-level entity. It's a versatile term that encompasses various types of groups, whether they're businesses, non-profits, or informal collectives. This choice sets a solid foundation for your application's data model and helps avoid confusion as your product evolves.

Different applications handle user access in various ways. Some allow a single user account to access multiple organizations (like GitHub), while others require separate accounts for each organization (similar to some Google services). There's also the approach used by the Linear app, which combines elements of both models. It allows users to access multiple organizations from a single account while also supporting separate accounts when necessary.

For most SaaS startups, a flexible model similar to the one used by the Linear app is ideal. It provides the best of both worlds, accommodating both individual and organizational use cases without imposing unnecessary constraints on the user.

In a multi-tenant system, it's essential to ensure that each organization's data is securely isolated from others. Think of it like an apartment building: residents share common spaces but have private living areas with controlled access. Your application should allow for similar isolation and shared access, supporting both individual use and collaboration within and across organizations.

Most resources in your application should belong to an organization rather than to individual users. This structure simplifies data management and enhances security. It also makes it easier to implement features like assigning tasks or projects to specific team members within an organization.

A critical aspect of multi-tenant functionality is the user experience around switching between organizations. Users should be able to move from one organization to another without having to log out and log back in. This seamless transition enhances usability, especially for consultants, freelancers, or anyone who collaborates with multiple organizations.

Implementing this requires thoughtful session management and authentication design. By allowing concurrent user sessions across multiple organizations, you provide a smoother and more intuitive experience that can set your product apart from competitors.

When it comes to billing, tie your subscriptions and payments to the organization rather than individual users. This approach aligns with how businesses manage expenses and simplifies account management for your customers.

Similarly, distinguish between global user settings and organization-specific settings. Global settings might include personal preferences like display themes, while organization-specific settings could cover notification preferences or role-based permissions. This separation ensures that users have a consistent experience across different organizations while still accommodating the unique needs of each group.

Implementing organization-level analytics from the start is vital. It not only helps you understand how your product is used but also provides valuable insights to your customers. By tracking usage patterns, you can make data-driven decisions to enhance your application and demonstrate value to your clients.

Designing your system with scalability in mind will save you from costly refactoring efforts in the future. Consider supporting features like parent-child organization relationships or accommodating various organization types. This foresight positions your product to handle increased complexity as your user base grows.

Integrating "teams" functionality from day one isn't just a technical decision—it's a strategic move that positions your SaaS product for long-term success. It aligns your software with the collaborative nature of how people work today, enhances user satisfaction, and makes your product more adaptable to a variety of use cases.

By anticipating your users' needs and building a flexible, multi-tenant architecture from the outset, you'll save yourself significant headaches down the line. More importantly, you'll create a product that not only meets but exceeds user expectations, setting the stage for sustained growth and success in the competitive SaaS landscape.

Building Multi-Tenant SaaS: Why "Teams" Functionality Should Be Day One Priority

Well, we've already made it a third of the way through the year. I'm wrapping up my honeymoon as I type this, and taking a break from work has been a nice refresh. It allows me to catch up on books and articles I've saved for later, and take a step back for a bit to refresh my perspective.

Recently, my preferred platform for media consumption has become Substack. I've just been gobbling up some great content on there! It's inspired me to sit back down at the old virtual writing desk, and take a stab at sharing some of what I've learned and found interesting recently with others who may fall in my digital bubble. In this post, I feel like writing about games, artificial intelligence, and compliments.

Here is a set of learning resources that I've put together on artificial intelligence, that should be fairly easy to digest, even if you aren't super technical:

One Useful Thing - Ethan Mollick's Blog on Practical Applications of AI in Learning and Business

Schillace Laws - A set of rules for how to best work with large language models as a software developer, written by Sam Schillace, deputy CTO at Microsoft and creator of Google Docs.

Prompt Engineering Guide - A lovely little site that goes in depth on different prompt engineering techniques with helpful examples.

A16Z - Andreesen Horowitz is one of my favorite VC firms to follow. They have a lovely collection of thought leadership on AI.

GitHub's Blog - I have long been a fan of GitHub's blog and R&D arm, GitHub Next. They have some fantastic material.

AI Pollution and the Tragedy of the Commons

If you haven't noticed the endless barrage of AI-generated images and "thought leadership" content on LinkedIn by now, you are either 1) not in the tech industry or tangential to it or 2) have been living under a rock. One of the more cringe-inducing features on LinkedIn that has recently fallen victim to this is the short-form "Answer a question" feature (you can do better LinkedIn).

Now, it's impossible (although some say the inclusion of the word "delve," or the wrapping up of a blog post with "In conclusion," are telltale signs of using Chat-GPT) to know for sure if these responses are AI-generated or assisted. Either way, there's a lot more content like this floating around nowadays, because it's just so easy to create now with LLMs. What are getting ourselves into? Maybe we need to revisit introducing more "Dislike" actions, like Facebook considered almost a decade ago.

A lot of people think the rapid uptick in low-quality content generation enabled by generative AI will “kill” the internet or drastically change it. It probably will. What will we see next though? Humans are resilient and innovative, so I’m looking forward to the next version of it. Are humans capable of designing a platform that prevents the tragedy of the commons, which doesn’t rely on an economy of eyeballs and clicks? In 2004, Aaron Swartz wrote a blog post about information freedom. Can information be regulated? Is there a technical solution to this, or do we rely on a collective swing of society to have a conscious positive impact?

In 2014, Warren Berger claimed in his book “A More Beautiful Question” that posits that questions are now more powerful than answers, because questions lead to innovation, and information is now freely and widely accessible. His rationale, is that it is inevitable that human information would become stored in a database that we could all access.

The sheer amount of information humans rely on to take action now is far too great for any brain to hold. So for the last two or three decades, we've been heading towards a world in which we gain the vast amount of our information from databases. And now, more recently, a computer (e.g., Chat-GPT) tells us the best information collected from the best resources. While this can sound daunting to some, there there is a tremendous upside to this - reduced decision fatigue.

I love Lazarus Lake’s approach to game design. He is something of a celebrity in the ultra-running community. He cropped up on my radar recently, after reading Frank Lantz's wonderfully eloquent piece on him. You should read it. Also, Lazarus Lake spoke on a podcast recently that is equally worth consuming. What I'm so enamored with is how he's bending seriousness, but not disregarding it. Lake's games remind me of Thorsten Brinkmann in some ways, blending ceremony with the peculiar. Lantz articulates it far better than I can, with the following quote:

"When they aren’t trying to manipulate you, most modern games are desperately trying to please you, carefully designed to capture and hold your attention, constantly trying to explain and justify themselves, and sweatily working to amuse and entertain you. When your game is a product every sharp edge is a flaw, a leak, an opportunity for the precious attention you are harvesting to escape back into the ether. Lake’s games are also carefully designed, they are full of closely-considered details that fit together to make a coherent whole, but the problem they are trying to solve is an entirely different one. They are not bowing and scraping to accommodate your needs while secretly plotting to hypnotize you into a state of passive thrall. Their parts fit together like the plants, rocks, and mud of a Tennessee mountain, and, like that mountain, they will happily, indifferently, shrug you off. And yet, somehow, the resulting experience expresses a deep level of respect and compassion." -Frank Lantz

Take some of these rules from Lazarus Lake's infamous Barkley Marathon that is organized each year and notoriously difficult to register for:

The start time occurs between midnight and noon. However, racers are never told when the race will officially start. The only indication they receive for the start time is by Cantrell blowing a conch shell, which could come in the middle of the night, to signify that the race will start exactly one hour from that time.

Once the hour is up, runners line up at the yellow gate at a campground within Frozen Head State Park. When Cantrell lights a cigarette, that starts the race along with the clock.

The bib is very important in this race. It does not track the runner or splits; rather, each loop requires runners to make it to various points in the park. At those checkpoints are books that Cantrell has placed there. Your bib number is the page number you need to rip out of that book. Typically, nine to 11 books are placed in the woods, and if you are missing a page then you didn’t officially complete the loop.

I hope some day to design a game. It's... somewhere... on my bucket list. Not sure when I will, but when I do, I plan on drawing inspiration from Lazarus Lake.

The other day I ran into a long-time friend of mine whom I rarely see (the older sister of one of my close high school friends). She shared with me that the mix CDs that I burnt for some of my friends, including her sister, made a lasting impression on her musical preferences, and she was thankful for that. It was very kind of her to share that with me, and it made my day. I sometimes forget how powerful and energizing a sincere compliment can be in the receiver's life. If you're reading this, thanks for that A.H.!

Here are some things I've found enjoyable recently:

Book: "Scaling People: Tactics for Management and Company Building" -Claire Hughes Johnson

Song: "Agape" -Nicholas Britell (fun fact, he wrote the theme for Succession)

TV: Succession (I've recently jumped into it, and am loving it! It's one of those series I knew would be good, but held off on watching for a while)

I've recently gone down quite a rabbit hole with Frank Lantz and intend to read "The Beauty of Games" in full here shortly. I also plan to read "Gravity's Rainbow," because I'm a bit obsessed with Thomas Pynchon's concept of temporal bandwidth.

Some of my favorite takeaways from day 1 at Figma's Config 2023 Conference, which was jam-packed with some quality presentations from heavy-hitters in the tech and design communities.

The first day of Figma Config 2023 was jam-packed with talks from some heavy hitters in the design and tech communities. This is a recap of some of my favorite sessions of the day, related to the creator community and the characteristics of delightful software.

John Salvie

Oct 14, 2025

How AG-UI Makes Agents Feel Human

Sep 8, 2025

Building AI-Enabled Systems That Think, Remember, and Collaborate

Dec 10, 2024

Takeaways from AWS re:Invent 2024

Dec 10, 2024

How Amazon SageMaker’s Next Evolution Simplifies Your Data and AI Stack

Dec 9, 2024

AWS Overhauls S3 and Databases to Support AI and Analytics Workloads

Dec 6, 2024

Simplexity in Building at Scale

Nov 15, 2024

Building Multi-Tenant SaaS: Why "Teams" Functionality Should Be Day One Priority

Apr 29, 2024

Ramblings on AI and Lazarus Lake

Jun 23, 2023

Figma Config 2023 Day 1 Recap: Delightful Design and Empowering New Creators

Jun 20, 2023

Hidden Gems in Plain Sight

Apr 20, 2023

Nostalgia for a Messier Web: The Charm of the Past and the Impact of Modern UI Frameworks

Mar 8, 2023

Moving Beyond Traditional User Stories to Component-Centric Requirements

Feb 10, 2023

The Future of Enterprise Systems: Composable and Low/No-Code Solutions

Jun 27, 2022

Embracing Slowness

Jan 18, 2021

RICE: A Simple Approach to Prioritizing Product Development