标签：#architecture

Your backend returned 200. The mobile app showed an error. The user tapped "Pay" three times. Three pending charges hit their account. One order was placed. Their balance was short. And your incident log showed zero failures. Every engineer on the team did their job. Nobody solved the problem. This is the most common way engineering teams fail, not through incompetence, but through excellent execution of the wrong unit of work. And until you recognise the difference between completing a task and solving a business problem , you will keep shipping systems that work perfectly and experiences that don't. The Ticket-Thinker vs. The System-Owner Most engineers early in their careers think in tickets. Ticket assigned → code written → tests pass → PR merged → ticket closed. Done. This is fine when you're learning. It's a liability when you're trying to grow. The engineer who closes tickets is useful. The engineer who asks "what problem does this ticket actually solve, and am I solving it in the right place?" that engineer is dangerous in the best way. Here's the distinction in practice. The backend engineer builds a payment endpoint. It processes charges correctly, returns the right status codes, has proper error handling. 100% test coverage. Ticket closed. The mobile engineer builds the payment screen. It calls the endpoint, handles the response, shows confirmation or error. Smooth UI. Ticket closed. The problem nobody owned: what happens when the network drops after the backend processes the charge but before the mobile app receives the confirmation? The backend: charge processed. No error. The mobile: timeout. Shows "Payment failed." User retries. The user: charged twice. Both engineers solved their assigned problem correctly. The business problem — charge the user once and confirm it reliably — went unsolved. Because that problem lived in the space between their tickets, and nobody was watching that space. Real Scenario 1: The Payment That Worked and Failed at the Same

The first two articles in this series each showed one technique. Implementation notes #001 was a dynamic dropdown — a form field that fills itself from an API. Implementation notes #002 was a dynamic credential — an API key that arrives from the form and threads through to the HTTP nodes. This article is the capstone. It walks through all-services-demo , the example workflow that ships with n8n-nodes-ldxhub , where those two techniques combine with a Switch node to host five different AI document-processing services inside one workflow — structured extraction, translation refinement, OCR, PDF conversion, and text extraction. The screenshots and the workflow JSON below come from the n8n-nodes-ldxhub package. The patterns themselves are generic — they work for any set of services you want to consolidate into a single template. This is not a "follow these steps" article. It's a parts catalog. No two readers are solving the same problem, and templates rarely fit anyone's situation as-is. Take what fits. Drop the rest. You don't need to understand all 46 nodes to reuse the patterns. The shape The workflow has 46 nodes — large enough to look intimidating in the editor, but structurally it's just five repeated paths plus a small routing section. The entry section is two nodes: On form submission — the trigger. Asks the user which service they want and collects an API key. Route by Service — a Switch node with five outputs, one per service. Everything to the right of the Switch is service-specific. Five paths fan out: StructFlow, RefineLoop, RenderOCR, CastDoc, ExtractDoc. Each path ends in two Form Ending nodes — one for success (auto-downloads the result), one for error. That's the spine: form → switch → service path → ending. The complexity is pushed into the service paths. The spine: routing by static comparison The Switch node ("Route by Service") uses Rules mode. Each rule reads the same expression from the form — {{ $json.service }} — and compares it to a static serv

A founder told me last year: "We need admin features shipped by Friday. Can we just hardcode the roles for now?" That was 7 months ago. They're still paying for that decision today. This article is the breakdown I wish I had given them before that Friday — the patterns that separate a quick MVP version of RBAC from one that won't bite you back in six months. If you're a startup CTO, technical founder, or senior engineer about to ship admin/dashboard features for the first time, this is for you. The 4 signs your RBAC is a time bomb I've reviewed this exact pattern in 5+ early-stage codebases. Every one of them eventually hit the wall. Look for these signs: 1. Roles hardcoded in the JWT { "sub" : "user_123" , "role" : "admin" } Simple. Until you need to: Add a new role → migration + token refresh strategy Give one user a temporary elevated permission → "we'll just reissue tokens" Audit who had admin last month → good luck 2. Permission checks scattered across 40+ controllers // In every single handler: if user . Role != "admin" { return c . Status ( 403 ) . JSON ( ... ) } By the time you have 30 endpoints, you've made the same mistake 30 times. Refactoring is a full sprint. 3. One admin superuser that can do everything Until a sales rep accidentally deletes a customer record because they were elevated to admin "just for that one task last week." 4. Zero audit trail When the data goes missing, your only investigative tool is git blame on the source code and a desperate grep through CloudWatch logs. If you've nodded at any of these — keep reading. The real problem: policies-as-code Most teams treat permissions like business logic. They live in source files, gated by if statements, deployed with the rest of the code. This is the original sin. Code changes need deploys. Permissions change daily. When marketing onboards a new role next quarter, when a customer success rep needs view-only access to billing, when legal asks "who could have read this customer's data on Tuesda

Ask a language model to score a developer portfolio out of 100 and you get a confident number back. Hand it a near-empty page with a name and a broken avatar, and it will often still tell you something like 92. Nice layout. Strong personal branding. The model is being polite, not accurate. That was the first wall I hit building Leon, the reviewer inside getfolio. If the score is not trustworthy, nothing downstream matters: the critique, the suggestions, and the fix button all hang off a number the model invented to sound encouraging. This is the build log of how I stopped letting the model hold the pen. Short version: a deterministic rules engine owns the score, and the language model only owns the words around it. The failure mode: an LLM judge wants to be liked If you have shipped anything with an LLM evaluator you have probably seen this. You hand it a rubric, a JSON schema, even worked examples, and it still drifts upward. Empty inputs get encouraging scores. Weak inputs get the benefit of the doubt. Strong inputs land in the same band as the weak ones, just with longer praise. A few reasons, roughly in order of how much they hurt: Tuning rewards a helpful, encouraging tone. Harsh scoring reads as unhelpful, so the model softens it. The model has no ground truth for what a 70 versus an 85 looks like in your specific domain. It is scoring on vibes. Scoring and explaining are entangled. The model writes the kind explanation first, then picks a number to match the nice things it just said. Run it twice on the same input and you get two different numbers. There is no anchor. For a portfolio reviewer that real recruiters and developers would act on, that was a non-starter. If Leon says 64, an empty page should not be able to reach 64 by accident, and a strong portfolio should not get talked down to it either. The number has to mean something. The fix: rules engine owns the score, model owns the language The architecture splits responsibilities hard. A deterministic e

"An AI agent just built a production landing page, with GDPR audit logs and encryption baked in. I wasn't even at my desk." That is not a lucky one-shot. It is a repeatable workflow. Piotr Karwatka recorded a full tutorial showing how to go from idea to a production-ready app on Open Mercato - the AI-Engineering Foundation Framework for CRM/ERP - with no babysitting and no ping-pong prompting. This is the technical version: what the loop actually looks like, why it doesn't fall apart, and which patterns you can lift into your own stack. The problem with conversational coding The default AI coding loop is single-threaded and human-bound: prompt -> generate -> you spot a bug -> correct -> re-prompt -> repeat It holds for snippets. It collapses the moment the task touches real architecture - multi-tenancy, RBAC, event flow, encryption, audit logging. Corrections pile up in the context window, the agent loses the thread, and you are back to typing. You are the bottleneck, sitting in the inner loop. The workflow in the tutorial moves you to the outer loop : you review a finished, tested PR instead of every keystroke. goal -> agent: branch + implement + test + open PR -> you: review PR The reason this is even possible on Open Mercato is that the hard architectural decisions are already encoded as conventions, specs and agent-readable skills ( AGENTS.md , task routing, spec skills). The agent is not inventing how RBAC or GDPR logging should work - it reads the foundation and follows it. 1. Fire-and-forget: the autonomous PR loop The execution agent owns the full unit of work: 1. git checkout -b feat/lead-capture-landing 2. implement against framework conventions 3. run the test suite (Playwright integration tests included) 4. open a structured PR: what changed, why, how it was verified You are no longer correcting tokens. The deliverable is a reviewable artifact. In the tutorial the output is concrete: a live site capturing leads straight into the Open Mercato CRM, with GD

Lately I keep reaching for SQLite where, before, I'd have reached for Postgres without thinking. It started with small services, then a bigger question: could a multi-tenant SaaS actually run on SQLite? And for AI agents specifically, isn't a local, embedded database the more natural home for their state? Turso is the version of this stack I've found most compelling so far, especially when paired with Cloudflare. I wish D1 would reach embedded-replica parity with Turso, and that AWS offered a managed SQLite-style service the way it offers RDS for Postgres. This isn't a "Postgres is over" argument. I still use Postgres more often than SQLite. And it isn't advice. It's just where my thinking has drifted recently — written down mostly so I can find out where it's wrong. Read it as one person's notes, not a recommendation. Where I've landed for now (and expect to keep revising): SQLite isn't replacing Postgres. For work state , it's increasingly my first reach, not my last. AI agents push this harder: their state is high-churn, local, and mostly private. The answer isn't all-local. It's a local workbench plus a central ledger . Why the old default existed For years, "where does the data live?" had one practical answer: a server, behind an API, in a shared Postgres. A lot of that wasn't architecture — it was the cheapest shape available. SQLite was already everywhere, but it lacked the operational layer that makes a database viable as SaaS infrastructure: networking, replication, managed backups, and a way to run many small databases without drowning in tooling. So centralizing was the path of least resistance, and a tenant_id column in shared Postgres became the reflex. What changed isn't SQLite. It's that the ecosystem grew the missing parts — and for a growing class of workloads, the thing doing the most frequent writing moved onto my own machine. The constraint that's lifting SQLite itself is, by design: Embedded, not networked — a library, nothing listens on a port.

When was the last time you deleted an email account on purpose? For most teams the answer is never, and that tells you something. We treat mailboxes the way we treated servers in 2008: hand-built, carefully named, kept alive indefinitely because recreating one is painful. They're pets. Meanwhile every other piece of our infrastructure — compute, queues, databases — became cattle: numbered, provisioned by code, destroyed without sentiment when the job ends. Email is finally catching up. With Nylas Agent Accounts (in beta), a mailbox is created with one call and destroyed with another, and that symmetry is the whole point. The full lifecycle in two commands Provisioning, from the CLI: nylas agent account create signup-agent@agents.yourdomain.com Or via POST /v3/connect/custom with "provider": "nylas" — no OAuth, no refresh token, just an address on a domain you've registered. Teardown is equally unceremonious: nylas agent account delete signup-agent@agents.yourdomain.com --yes (The API equivalent is a DELETE on the grant.) The signup automation recipe treats this as a loop: provision a fresh inbox, point a third-party signup form at it, catch the verification email through a message.created webhook, follow the confirmation link, delete the grant. No human inbox involved at any step, and nothing left behind. The middle of that loop is about twenty lines of webhook handler, and the recipe's version filters hard before acting — right grant, right sender, right URL shape: const { grant_id , id : messageId , from } = event . data . object ; if ( grant_id !== AGENT_GRANT_ID ) return ; const sender = from [ 0 ]?. email ?? "" ; if ( ! sender . endsWith ( " @saas-you-care-about.example.com " )) return ; const match = /https: \/\/ saas-you-care-about \. example \. com \/ confirm \? token= [^ " \s < ] +/ . exec ( message . body , ); if ( match ) await fetch ( match [ 0 ]); Nylas fires message.created within a second or two of mail arriving, so the whole signup round-trip typical

To build one family’s dream house on a flood-prone Mississippi bayou, AD100 architect Tom Kundig decided the sky’s the limit.

I think a lot of people still imagine AI coding as opening ChatGPT, asking for code, and copy-pasting the result. That's not really how I work anymore. The biggest shift for me is that planning matters far more than coding. Earlier, execution was expensive, so most of the effort went into writing code. Now execution is cheap. I can have an agent implement something in minutes. The hard part is making sure the plan is correct. Most of my effort goes into thinking through the architecture, edge cases, failure modes, test strategy, and how the change fits into the broader system. If the plan is vague, the agent will confidently implement the wrong thing. The quality of the result is mostly determined by the quality of the plan. Once I have a plan, I break it into small independent pieces. Each piece should be executable without additional clarification. If an agent needs to stop and ask questions, the task probably isn't broken down enough. Those pieces become tickets. Then an agent picks up a ticket and implements it. The important thing is that the agent isn't operating in a vacuum. I try to give it a good environment to work in: Clear architectural rules Reusable skills and workflows Guardrails Hooks for things that must always happen One lesson that really stuck with me is that instructions are guidance, not guarantees. At one point I had "always use a git worktree" written in AGENTS.md. The model still ignored it occasionally. When I dug into it, the answer was simple: models can drift from instructions. So if something absolutely must happen, don't rely on instructions. Enforce it. Put it in a hook, script, validation step, CI check, or some other deterministic mechanism. If it is important, make it impossible to skip. Once the implementation is done, the agent opens a PR. This is where another useful pattern comes in: don't let the same model review the code it wrote. I usually have one model implement and another model review. Different models catch different t

From friend compounds and meditation spaces to shaded outdoor areas and rooms just to make coffee, homes are getting even more multipurpose.

Buying a first house used to mark entry into adulthood—and the beginning of wealth-building. But a shifting economic landscape is threatening to close the door on this American milestone.

How many times have you seen a picture of a plane with red dots posted on the internet without context? There's a famous story about a statistician named Abraham Wald and a bunch of WWII bombers. The military looked at the planes coming back from combat, mapped where they were riddled with bullet holes, and decided to add armor there. Wald, being the kind of person who ruins meetings by being right, pointed out the obvious thing nobody wanted to hear: The planes they were looking at came back . The ones hit in the spots with no bullet holes, the engine, the cockpit, were at the bottom of the English Channel, not available for the survey. Reinforce the parts that aren't shot up. That's where the dead planes got hit. I think about this story a lot, mostly while reading those blog posts titled "X Habits That Made Me a 10x Engineer." The entire industry is a returning-plane survey Here is the uncomfortable thing about software engineering wisdom: almost all of it is collected from the planes that came back. Successful companies write blog posts. Successful founders do podcast tours. Successful engineers give conference talks with titles like "Scaling to 100 Million Users with Three People and a Dream." The companies that did the exact same things and died do not have a booth at the conference. They are not on the panel. They are in the channel, with the engines. And yet we keep doing the survey. We stare at the bullet holes on the survivors and go, "Ah, this is where we add armor." "Netflix uses microservices, so we should too" You have eleven users. Three of them are your co-founders, and one is your mom. Netflix runs a globe-spanning streaming empire on hundreds of microservices because they have hundreds of teams, billions in revenue, and problems you will be lucky to have in a decade. You have a Postgres database that is doing just fine, thank you, and a monolith that boots in four seconds. So naturally, you spend the next eight months splitting your perfectly funct

Every engineering team hits this conversation at some point. Someone proposes GraphQL. Someone else says REST is fine. A third person mentions gRPC and half the room goes quiet. The debate usually ends with the most senior person in the room picking what they're most familiar with. That's not a strategy — that's habit. Here's an objective breakdown of all three, when each one wins, and how to actually make the decision for your specific use case. The Core Mental Model Before comparing them, understand what each one is optimizing for: REST optimizes for simplicity and broad compatibility GraphQL optimizes for flexibility and precise data fetching gRPC optimizes for performance and strongly-typed contracts None of them is universally better. Each one is a tradeoff. The right answer depends entirely on who is consuming your API and what they need from it. REST — The Default That Still Wins Most of the Time REST (Representational State Transfer) is not a protocol. It's an architectural style built on HTTP — verbs, URLs, and status codes most developers already understand. Where REST genuinely wins: Public APIs. If external developers are consuming your API, REST is the only reasonable default. The tooling, documentation patterns, and developer familiarity are unmatched. Stripe, Twilio, GitHub — all REST. Simple CRUD services. If your resource model is straightforward, REST maps cleanly to it. No overhead, no learning curve, no ceremony. Browser-native requests. REST over HTTP works directly in the browser without any special client. Fetch it, done. Where REST struggles: Over-fetching and under-fetching. A single REST endpoint returns a fixed shape. Mobile clients that need 3 fields get 40. Separate data needs often require multiple round trips. Versioning overhead. As covered in our previous post — every breaking change forces a versioning decision. This compounds quickly on complex APIs. GraphQL — Powerful, But You Need to Earn It GraphQL is a query language for your A

Not every failure is permanent. This is something I didn't think about before. When something fails in my app, my first thought was something broke, fix it. But when I started learning how distributed systems actually work, I realized that some failures are not really failures. They're just temporary. Network glitch. API timeout. A service that just restarted. Rate limiting kicking in. These are all failures but they last for a very short time window. If your system tries the same operation again after a few seconds, it will probably succeed. So the question is does your system know how to try again? Or does it just give up the first time something goes wrong? That's what retry is. What Retry Actually Does Without a retry system, if a temporary failure happens that's it. The entire operation fails. The user sees an error. The request is gone. With retry, your system automatically attempts the operation again after a failure. The goal is simple recover from temporary failures without the user even knowing something went wrong. This felt obvious to me once I understood it. But building it properly is where it gets interesting. The Configuration: What Each Part Controls When I looked into how retry systems are actually configured, there were more options than I expected. And each one exists for a specific reason. maxAttempts — this defines the maximum number of times the operation can be attempted. You don't want infinite retries. At some point if it keeps failing, it's probably not a temporary problem. exponential backoff — instead of retrying immediately every time, the delay between retries doubles after each failure. First retry after 1 second, second after 2 seconds, third after 4 seconds. This gives the failing service time to recover instead of bombarding it with requests. baseDelay — this is the starting delay used in the exponential backoff. The first wait time before retrying. maxDelay — this caps the maximum delay. Without this, the exponential backoff keeps

Most AI demos work perfectly on a laptop. But production AI systems can become fragile when everything is handled inside one synchronous API call. A user sends a request. The API extracts text. The API chunks the content. The API generates embeddings. The API stores data. The API waits for everything to finish. This may look simple in a demo, but it quickly becomes a problem in real systems. The problem with one giant API call In many AI applications, the API is expected to do too much. For example, in a document processing or RAG pipeline, one request may trigger multiple heavy steps: text extraction chunking embedding generation indexing summarization database updates If all of this happens inside one synchronous request, the API becomes slow and fragile. If one downstream step fails, the complete request may fail. If traffic increases suddenly, the API may become overloaded. This is why event-driven architecture becomes useful for AI workloads. A better approach: API + Kafka + workers Instead of making the API do everything, we can split the workflow into smaller services. The API accepts the request and publishes an event. Background workers consume events and continue the processing asynchronously. A simple flow looks like this: User Request ↓ FastAPI ↓ Kafka / Redpanda Topic ↓ Python Worker ↓ Next Processing Stage In my practical demo, I am using: FastAPI Redpanda Python workers Docker Compose Kafka-compatible messaging Why Redpanda? Redpanda is Kafka-compatible, which makes it useful for local demos and event-driven architecture experiments. It allows us to work with Kafka-style topics, producers, and consumers while keeping the setup simple for development. What this architecture gives us This approach helps with: decoupling services handling bursty workloads moving long-running tasks to background workers improving scalability isolating failures building production-style AI pipelines This pattern is especially useful for AI systems involving: document proce

This is an adapted excerpt from a guide in my AI Knowledge Hub. The full interactive version is linked at the end. Agentic design patterns are named control structures for arranging LLM calls and tools. This post gives you the decision rule for picking one, the exact shape of each pattern, and the cost each adds — so you can match a task to the minimum structure that solves it. Everything here is model-agnostic and grounded in Anthropic's Building Effective Agents and the Claude Agent SDK. Workflow vs. agent: the split that decides everything Anthropic divides all agentic systems into two categories, and the split decides every downstream tradeoff: Category Definition Control lives in Use when Workflow LLMs and tools orchestrated through predefined code paths Your code You can pre-map the decision tree; want accuracy, control, lower cost Agent LLMs dynamically direct their own processes and tool usage , maintaining control over how they accomplish tasks The model Open-ended task where you can't predict the number of steps Every pattern composes one unit: the augmented LLM — an LLM enhanced with retrieval, tools, and memory. It generates its own search queries, selects tools, and decides what to retain. If a single augmented LLM call solves the task, stop — no pattern required. The escalation rule is the whole game: find "the simplest solution possible, and only increasing complexity when needed" — which "might mean not building agentic systems at all." Agentic systems trade latency and cost for better task performance, so only escalate when a specific failure mode forces it. The agent loop: gather → act → verify → repeat For open-ended tasks, every agent runs the same four-beat loop: Gather context — read files, run agentic search ( grep / find / tail to pull relevant slices instead of whole files), or delegate to subagents with isolated context windows. Take action — execute via tools: bash, code generation, file edits, MCP servers. Verify work — check the result b

Anyone who's wired an autonomous agent into email and calendar the traditional way knows the identifier sprawl: an OAuth client ID, a refresh token per user, a Gmail-specific message ID format, a Microsoft Graph calendar ID, and a webhook subscription ID for each — all with different lifetimes, all able to break independently. Half your "integration" code is really identifier bookkeeping. Nylas Agent Accounts collapse all of that into one value. When you create an account (the feature's in beta), the response hands you a grant_id , and that single string is the handle for everything the agent does — mail, calendar, contacts, attachments, and the webhooks reporting on all of them. One ID, the whole surface Every operation addresses the same path family, /v3/grants/{grant_id}/* : POST /v3/grants/{grant_id}/messages/send # send mail GET /v3/grants/{grant_id}/messages # read the inbox GET /v3/grants/{grant_id}/threads/{thread_id} # full conversation GET /v3/grants/{grant_id}/attachments/{id}/download POST /v3/grants/{grant_id}/events # host a meeting POST /v3/grants/{grant_id}/events/{id}/send-rsvp # respond to one GET /v3/grants/{grant_id}/contacts GET /v3/grants/{grant_id}/rule-evaluations # audit trail This isn't an abstraction invented for agents — an Agent Account is literally just another grant, the same primitive used for connected Gmail and Outlook accounts. The supported endpoints reference puts it as "same endpoints, same auth, same payloads." Anything you built for connected accounts works against an agent's grant unchanged. And the resources behind the ID are real: six system folders provisioned automatically ( inbox , sent , drafts , trash , junk , archive ), a primary calendar that speaks standard iCalendar, and outbound messages capped at 40 MB total. Webhooks route by it too The inbound side completes the picture. You subscribe once at the application level, and every notification — message.created , event.updated , message.bounce_detected , and the rest

Week one: a single test mailbox on a trial domain, provisioned by hand from the dashboard. Week twelve: a fleet of agent mailboxes spread across customer domains, each sending real mail with its own quota and reputation. The API calls are the same at both scales — what changes is everything around them: how you provision, how you share configuration, and how you keep one bad sender from pausing the fleet. Here's what the path from one to thousands looks like with Nylas Agent Accounts , which are currently in beta. Provisioning is a loop, not a ceremony There's no OAuth dance to scale around. Creating a mailbox is one POST with "provider": "nylas" — no refresh token, no consent screen — so a fleet provisioner is just iteration: curl --request POST \ --url "https://api.us.nylas.com/v3/connect/custom" \ --header "Authorization: Bearer <NYLAS_API_KEY>" \ --header "Content-Type: application/json" \ --data '{ "provider": "nylas", "workspace_id": "<WORKSPACE_ID>", "settings": { "email": "agent-0042@agents.yourcompany.com" } }' Two scaling-relevant details in that request. First, the domain: one application can manage accounts across any number of registered domains, and the docs explicitly recommend splitting high-volume outbound across multiple domains ( sales-a.yourcompany.com , sales-b.yourcompany.com ) so reputation damage on one doesn't contaminate the rest. Second, the workspace_id : passing it at creation is how each account picks up its configuration, which brings us to the part that makes fleets manageable. Configure workspaces, not grants At fleet scale, per-grant configuration is a non-starter. The model here is indirection: policies and rules attach to workspaces , and every account in a workspace inherits them. One policy object — daily send quota, storage cap, retention windows, spam sensitivity — governs a thousand mailboxes, and updating it updates all of them at once. The recommended carve-up is one workspace per agent archetype: outreach agents get a work

Every Agent Account you create lands in a workspace — the only question is whether you picked it or the platform did: curl --request POST \ --url "https://api.us.nylas.com/v3/connect/custom" \ --header "Authorization: Bearer <NYLAS_API_KEY>" \ --header "Content-Type: application/json" \ --data '{ "provider": "nylas", "workspace_id": "<WORKSPACE_ID>", "settings": { "email": "test@your-application.nylas.email" } }' That top-level workspace_id is optional, and what happens when you omit it is one of the more under-read parts of the Nylas Agent Accounts docs (the feature's in beta, so read with that in mind). Workspaces aren't cosmetic grouping — they're the carrier for every policy limit and mail rule that governs your agents. Getting placement wrong means an agent running with the wrong send quota, the wrong spam settings, or no inbound filtering at all. The placement algorithm When a new account is created, placement resolves in this order: Explicit workspace_id on the request — the account goes exactly where you said. The target workspace must belong to the same application; ownership is validated and mismatches are rejected. Auto-grouping by domain — if a workspace has auto_group enabled and its domain matches the new account's email domain, the account joins it automatically. The default workspace — everything else lands here. That third bucket is the interesting one. What the default workspace actually is Every application gets exactly one default workspace, created and managed by the platform. You can't delete it, and you can only update two of its fields: policy_id and rule_ids . Everything else is managed for you. It's easy to read "default" as "throwaway," but it's better understood as your safety net. Any account you forget to place explicitly — a quick test from the CLI, a provisioning script missing the workspace parameter — inherits whatever the default workspace carries. Which leads to a practical recommendation: attach a conservative baseline policy and

Series Final. The four mechanisms covered across this series — knowledge graph, Auto Review, Self-Healing, Recurrence Prevention — plus the non-engineer-PR application that sits on top of them, all hang off a single conviction: AI isn't something to trust; it's something to design. The 'I don't trust AI to fill in the blanks for me' framing this lives inside isn't doubt about generation quality, but the clear-eyed acceptance that AI has no idea what context wasn't handed to it, and that 'ideal behavior with no spec given' is a fantasy. The starting point goes back to 2025, when I was trying to figure out how to make AI actually understand a large codebase — and ran into walls on both context window scaling (lost in the middle, attention dilution) and learning-based approaches (machine unlearning, destructive interference). GraphRAG + MCP became the way out: hand AI only the facts it needs, when it needs them, so it doesn't have to infer. From code-graph (which I burned two months on and threw away) to the current product-graph (cpg). This piece is the philosophy and the trial-and-error behind the whole series: harnesses confine where hallucinations are allowed to happen, design is translating principles into your own use cases, and Coverage 90% as a solo target breaks the implementation.