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.

Day 1 of Figma's hybrid virtual/in-person conference, Config 2023, was practically seamless from a technical standpoint. There have been some real shit-shows over the past couple of years when it comes to virtual event productions. I know it's not an easy undertaking, so kudos to all involved in this year's production. Two talks that stood out were by Andrew Schmidt on delightful design and Amiad Masad on enabling new creators of software.

Andrew Schmidt, gave a delightful talk (pun intended) on the characteristics that embody good software, and how they're pre-requisites for creators to consider before pulling out their bag of overused tricks for novel/kitschy "delight" (think confetti, silly micro-interactions, and overly conversational UX copy). He proposed that delightful software should be tactile, inspiring, considerate, comfy, and empowering. At the end of his talk, he reiterated that when your software does characterize these different qualities, the icing on the cake is letting humanity shine through in your design. Just be careful not to get too "cute" with your product before accounting for those fundamental qualities.

Schmidt was one of the best conference presenters I have listened to in quite some time. Even if you're not that interested in the content, I highly recommend watching the video (skip to the halfway point to get to Schmidt's portion of the talk). His storytelling ability and presentation are top-notch.

Should designers c̶o̶d̶e̶ create software?

In another session, Amjad Masad, CEO of Replit, presented a thought-provoking talk on the evolving role of designers in the software industry. He proposed a shift in the question from "Should designers code?" to "Should designers write software?" This shift in perspective is significant. It suggests that designers should not merely be involved in the aesthetic and usability aspects of software but should also contribute to its creation and development. With the advent of AI-enabled platforms and tools, as well as a whole slew of low-code/no-code solutions available to consumers, I imagine the role of developers in the overall product development lifecycle will continue to diminish. The developer role will never go away entirely, but we will definitely see a stronger shift towards DesignOps over the next couple of years, with more focus on high fidelity prototypes and shorter development cycles.

Looking forward to tuning in for tomorrow's sessions. If you're interested in checking out the schedule, you can find everything on Figma's event page.

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

When organizations hire consultants, they often expect them to deliver specific outcomes. One lesser mentioned value-add from hiring consultants lies in their ability to see beyond their defined roles and notice high-value opportunities.

Friends and family often have a hard time understanding exactly what I do. Unlike other professions, consulting offers no shortage of unique challenges, tasks, and responsibilities. In my division of consulting (tech), consultants are typically hired by companies to provide unbiased perspectives or advice, to help establish architectures (product, technical, enterprise, data), or to build systems (products, integrations, automations, etc.) in order to help businesses thrive. We're expected to quickly navigate the intricacies of the digital landscape at a client and ramp up quickly on their specific tools, processes, org structure, and business domain.

During one of my team's projects, we stumbled upon a quick win that proved surprisingly valuable for our client. Our focus at the client was product development - we were simultaneously helping them modernize legacy apps and refactor their product architecture to support a "product through composition" model. When we started the initial design process to migrate Single-Sign-On (SSO) over from a systems standpoint, the client provided helpful context about their existing identity provider - including how much they were paying for it. While their existing identity platform was well-known in the industry, we wouldn't consider it one of our first picks if architecting from the ground up. Knowing this, combined with our newly learned cost considerations, we quickly provided a recommended alternative. Since we've implemented auth and identity solutions across dozens of clients, it was easy for us to identify an opportunity for improvement.

The client was open to exploring an alternative tool/platform, and approved a quick proof-of-concept that allowed us to validate that it would check all of the boxes. Once we validated it, it took less than one sprint (two weeks) to incorporate into the product. With the help of feature flags, we were able to deliberately roll it out to specific customers as we worked with their IT teams to coordinate the change.

This tooling overhaul had a couple of significant benefits:

From a cost standpoint, our client was able to realize cost savings of over $100,000 annually

From a product standpoint, the new platform had vastly superior documentation and integration/setup tooling. We were able to eliminate the need for our clients Solution Engineers to assist their customers with SSO setup, and move it to a 100% self-service model. Setup time shifted from days to minutes, and freed up valuable time for our client's engineers. 

Consultants bring a fresh set of eyes and an outside perspective to the table. We aren't tied down by internal biases or preconceived notions, allowing us to objectively evaluate systems and processes. In this particular case, our ability to question the status quo and identify potential areas for improvement set the stage for significant cost optimization and improved customer experience.

Regardless of your industry, or position at your company, you can have a positive impact on driving business value at your organization by considering the following practices.

Companies both large and small can benefit from establishing relationships with consultants. They can be extremely valuable contacts to have in your Rolodex. If you've never used a consultant before, feel free to reach out to me! I'd be happy to direct you to some of the people in my network that may be well-suited to help you. It's very much a relationship-based industry, so it can be difficult to find a place to start sometimes. Also, most consulting firms are generally happy to provide you some thought leadership and a project proposal at no cost. These can be helpful insights to help you decide who to go with from a partner standpoint. One other thing to note is that depending on the size of your firm, it can be helpful to diversify your partnerships with at least two - this will help ensure competitive pricing. Just be sure to foster a spirit of collaboration, not competition, which can easily kill the success of your most valuable initiatives.

Be open and transparent internally - both with your people and with external partners. Your best interests are generally in the best interest of your partners and your people. Air on the side of sharing information vs. gatekeeping it. Sometimes, even utilizing the appropriate workspace management platform can be a great first step in creating a community of collaboration.

Different industries have different appetites for failure. Define what failure and experimentation mean for your organization, and how you can leverage them to build value. Failing is good. It means you are experimenting. Spend some time with your team to see how you can intentionally create space for experimentation in your day-to-day. They can be the most valuable mechanisms for validating value. One way you can easily do this, is by allocating a percentage of your roadmap to exploration and experimentation.

Hopefully this short case study illustrates the potential value that consultants can bring beyond their defined roles and how, with or without consultants, you can create space within your organization to discover those hidden gems yourself. Thanks for reading!

As web development has evolved, modern design tools/systems like Material Design and Tailwind have undeniably facilitated acceleration and scale, leading to impressive advancements in the digital landscape. However, this progress has come at a cost—the charming, eclectic nature of the web's earlier days has been largely replaced by streamlined, uniform designs. In this article, we will reminisce about the "messier" web of the past and explore how modern design tools have contributed to a more polished yet less endearing digital world.

One of my all-time favorite sites is sreweb.com. I happened across it when seeing the URL called out in large block-letter signage of mismatched sizes and fonts on the side of a building from the highway. When I visited it, I was absolutely delighted - it was an absolute blast to the past, bringing back to the Geocities days. There was a time when the web was a wild, uncharted territory, with websites embracing a wide variety of designs, animations, and artistic expressions. Some aspects that made the web of the past so charming include:

Unique and Personalized Design: Websites were often handcrafted by individual developers or small teams, resulting in unique designs that reflected the creators' personalities and artistic visions.

Creative Freedom: The lack of established design patterns and best practices allowed for greater creative freedom, leading to a vast array of experimental layouts and visual styles.

A Sense of Exploration: The unpredictable nature of the early web fostered a sense of exploration and discovery, as users stumbled upon new and unexpected websites during their digital journeys.

The rise of modern UI frameworks, such as MUI, Ant Design, and Chakra (among many), has undeniably revolutionized web development, bringing significant benefits like improved performance, scalability, and maintainability. However, these frameworks have also contributed to the disappearance of the web's more charming aspects.

The widespread adoption of design systems has led to a more standardized design aesthetic, reducing the diversity and individuality of websites. As best practices and design patterns have become more established, developers are often encouraged to conform to these guidelines, potentially stifling creativity and experimentation.

John Salvie

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