{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibpv3lb33nayutvgntodelahq77gp7tb4y2b257tctye2vcweb4fi",
    "uri": "at://did:plc:keoe44tpmrccuqq2qnzotk6a/app.bsky.feed.post/3mky25d45aqd2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreieyajnbsggucmusislak5oxkbeexao6cdgijku5tiumnpaxo6jw7q"
    },
    "mimeType": "image/png",
    "size": 4346222
  },
  "description": "I have been thinking about time.\n\nNot in the philosophical sense. In the very practical, very marketed sense. The kind of time efficiency that fills my feed with promises. You will save so much time if you use this tool. You will get so much more done if you adopt this workflow. This did not work because you were not delegating to the right system.\n\nI started sitting with a question underneath all of that noise.\n\nWhat do you actually gain?\n\nNot the hours saved. Not the tasks completed. But the r",
  "path": "/designing-for-the-go-between/",
  "publishedAt": "2026-05-03T20:54:45.000Z",
  "site": "https://newsletter.heysukari.com",
  "textContent": "I have been thinking about time.\n\nNot in the philosophical sense. In the very practical, very marketed sense. The kind of time efficiency that fills my feed with promises. You will save so much time if you use this tool. You will get so much more done if you adopt this workflow. This did not work because you were not delegating to the right system.\n\nI started sitting with a question underneath all of that noise.\n\nWhat do you actually gain?\n\nNot the hours saved. Not the tasks completed. But the real human gain. Is it genuine or is it perceived? And if it is perceived, what are we actually trading it for? Are we gaining time or are we simply redistributing attention to a different kind of doing, one that feels more efficient because a system handled the part we found uncomfortable?\n\nThat question led me somewhere I did not expect.\n\nIt led me to my audience.\n\n### The design question nobody was asking.\n\n\nI work in email design. I build systems for design. And I started noticing something that did not have a name yet.\n\nThe people we design for are time-efficient movers. They are not passive recipients waiting for our content to arrive. They are actively delegating. Reminders, calendars, summaries, inbox management. They are using AI agents to handle the first pass of almost everything that comes into their attention space.\n\nWhich means the content we design is no longer arriving directly to the person we built it for.\n\nIt is arriving to the system they hired to protect their time first.\n\n__The blue sweater scene from__ _****The Devil Wears Prada****_ __is the best cultural reference for this moment. Andy Sachs thought her choice was entirely her own. But between the runway and her closet, a chain of decisions had already been made on her behalf, by editors, buyers, and systems she never saw.__\n\n__She was not outside the system. She was downstream of it.__\n\n__Your content is kind of in the same position. Between your send and your subscribers' or followers’ attention, a chain of evaluations has already happened. The subscriber or follower did not disappear. Their representative got there first.__\n\nAnd I started asking a question that I could not find anyone else asking.\n\nDo we think our audience is prompting the type of content they want to see and read? And if so, how do we design our content to feed into that prompt funnel?\n\nNot the human funnel we have been optimizing for decades. The prompt funnel. The one where the audience has already told an agent what they value, what they need, and what is worth their full attention. The one where our content is evaluated against that brief before a person ever sees it.\n\nI looked for frameworks that addressed this. I looked for language that named it. I found plenty of conversation about AI tools for designers. Plenty about productivity and workflow efficiency. Nothing about how design itself needs to change when the audience uses agents to decide what reaches them.\n\nThat gap is what made me stop observing and start building.\n\n* * *\n\n### What is the framework actually about?\n\n\nDesigned to Be Read is not a framework about artificial intelligence.\n\nIt is a framework about the go-between.\n\nThe time-efficient mover who has delegated their first read to a system. The inbox agent summarizing your email before the subscriber opens it. The semantic model evaluating your content against what it knows about the person it is protecting. The conversational algorithm deciding whether your work is worth passing through to the human it was built for.\n\nThese are not gatekeepers in the adversarial sense. They are representatives. Extensions of the subscribers or followers own stated preferences and priorities. They are doing exactly what they were hired to do: protect the time of the person who deployed them.\n\nThe design strategy changes when the human audience uses agents to prompt what they want to see in their day.\n\nThat sentence is the whole framework in one line.\n\nWe have been designing for the audience. We now need to design for the audience and the system representing them. Not instead of. In addition to. Two readers. One content system built to serve both.\n\n* * *\n\n### The four layers where this plays out.\n\n\nThe framework maps the shift across four connected layers, each one a surface where AI now mediates the relationship between your content and the person it was made for.\n\n**The Conversational Layer** is where systems ask. Platforms like Threads with Dear Algo, where the audience explicitly tells the algorithm what they want to see. Design for this layer means designing for stated intent. The audience has already told you what they value. The question is whether your content matches it.\n\n**The Semantic Layer** is where systems infer. Platforms like LinkedIn, where their model reads your content and draws its own conclusions about who you are and whether your work is worth distributing. Design for this layer means designing for coherence. Your profile, your posts, your engagement history, all of it is being read as a single argument about your credibility.\n\n**The Agentic Layer** is where systems act. Inbox agents, AI summaries, calendar integrations, notification managers. This is the go-between layer. The one where the subscriber's representative makes the first evaluation before the subscriber ever does. Design for this layer means designing for the summary that arrives before the open. Live text hierarchy. Semantic structure. Front-loaded meaning.\n\n**The Infrastructure Layer** is where the systems behind the systems operate. The standards, the protocols, the rendering environments that determine whether your content is even legible to the layers above it. Design for this layer means designing for machine readability as a first-order constraint, not an afterthought.\n\nMost creative teams are designing for the Conversational Layer and assuming the other three will sort themselves out.\n\nThey will not sort themselves out.\n\n* * *\n\n### What comes next?\n\n\nIt goes deeper on every layer, the standards for each one, and what the design practice looks like when all four are accounted for.\n\nFor those who want to go further, The Practitioner's Guide follows the framework with the audit standards, design checklists, and content design system guidelines you can apply immediately. It drops next week.\n\nThe audience is still human.\n\nDesign for both of them.\n\n— Sukari\n\n* * *\n\n**If something sparks a thought — or a disagreement — I'd love to hear it.** Share your thoughts or insights at **newsletter@heysukari.com**.\n\nWhat I hope you take away from reading is reasons to stay curious or to test the perimeter around trends, things to keep on your radar, and reasons to embrace fresh takes on the classics. — ****See you next Wednesday**** , Sukari",
  "title": "Designing for the Go-Between",
  "updatedAt": "2026-05-07T22:15:20.400Z"
}