AI tools keep getting better. But every session starts from zero. Your agent doesn't remember what the client rejected, what your design principles are, or the research behind the strategy. You re-explain everything, every time.

My biggest takeaways from @danshipper: 1. The future of work will happen inside Codex or Claude Code. Instead of putting AI into your SaaS tool, you’ll use your SaaS tools inside your favorite AI agents' in-app browser. Dan spends all his time in Codex now—writing documents, managing email, doing research, everything. He's using Google Docs, PostHog, and everything he needs within the agent's in-app browser. The agent can see what he’s doing, and has all of his context, so he and his agent collaborate quickly and super effectively. 2. Automation is a lie—every automation needs a human. Dan's company doubled in size this year despite being incredibly AI-forward. Why? Because in order to make automation work well, you need humans making sure everything keeps working. This is why benchmarks are misleading—they measure AI on problems we’ve already framed and can score, but there’s always a higher frame. 3. PMs will win the AI era. Marcus, a former PM who previously ran Axios’s writing product, joined Every after getting super AI-pilled. Now he runs their product Spiral, and ships faster than anyone on the team. He pairs technical knowledge with spiky product sense, deep user empathy, and an eye for what matters. Dan thinks any PM who gets really AI-native will be incredibly dangerous because the building is done for you—what matters is figuring out what to build and if it’s great. 4. Full-stack designers are becoming superheroes. Designers used to make beautiful interactions that engineers didn’t want to build or couldn’t execute properly. Now designers don’t need to hand things off; they can build it themselves. Designers are naturally creative people, and AI is the perfect tool for them because it lets them bring their vision to life without the traditional bottlenecks. 5. SaaS is not dead. In fact, Dan is bullish on SaaS stocks. When users bring their own AI (via Codex or Claude Code) to use SaaS products, the user—not the SaaS company—pays for tokens. This saves SaaS company’s margins. Since the agents need their own seats, Dan predicts that agents will create massive new demand for SaaS because there will be tons of agents using these products at high volume. 6. Every company will have one “super-agent” inside their Slack that every employee will use. Dan initially thought every employee would have their personal work agent, like a shadow AI org chart, but he’s completely flipped his view. He realized agents need humans who care about them. When someone gets tired of maintaining their personal agent, it becomes useless. The winning model is one forward-deployed engineer or AI-savvy person who maintains a company-wide agent (like Shopify’s River or Viktor), and then it trickles down to more specialized team agents as models improve and become less fiddly. 7. The AI job apocalypse is not happening, but you do need to evolve to stay relevant. Models make yesterday’s human competence cheap. But because everyone uses the same models, it all looks the same if you use it the default way; it becomes commoditized slop. Humans then take that frozen competence and use it to make something new and interesting for their specific situation. The key: “ride the models”—use them for everything you do, try new models when they drop, keep turning over rocks. 8. We will read way more AI-generated writing, and we will like it. Human writing is incredibly important for things that matter, but for internal docs, planning, and email, AI-generated is often better because most people are bad at writing strategy documents. 9. Build software for humans and agents to use together. The current model is building a CLI that an agent uses independently. Instead, you and your agent should be using the app together. This creates new design challenges—agents can make a billion requests in three seconds, so you need approval flows, inboxes that summarize what happened, logs, and easy rollback. 10. Forward-deployed engineers are the new most essential role. The big model companies have teams of people managing their internal agents, and those teams aren’t going away. It’s different from traditional software building, and certain engineers love it. As models get better, this role will evolve—you’ll be managing more agents doing more things.

The screen is doing a lot of work right now. Voice, vision, and space are modalities people and agents can share more naturally — AR being the first form factor that points at it. What comes after is harder to picture.

Been thinking about what this means for design practices. When making software is essentially free, the practice itself starts to look like a new kind of studio, closer to a product company than a services business.

This resonates. We are still very early in how we design for working with agents. A lot of the real innovation ahead will be in intelligent interfaces that let people see, direct, and collaborate with these systems more naturally.

Design as rendered care really resonates. What interests me about AI is whether it can help carry judgment, context, and intent all the way through the system. x.com/saleh_digital/status/2…

What feels important here is that agents need something they can actually reason over. Code carries structure, behavior, and intent more directly, which makes it a better substrate for the next generation of tools.

I have run a design firm for 14 years and the hardest thing to scale has always been tribal knowledge. How to think about design as a system of objects, not a collection of screens. When to push through ambiguity versus when to ask for help. How to read a client. These things take years to develop and they live entirely in people's heads. But they don't have to. Today, that knowledge can be captured, structured, and built on.

This is really impressive. The shift from "LLMs generate UI" to "LLMs generate apps" is the right framing. Deterministic aggregations on the runtime instead of the model is the kind of decision that makes this actually usable, not just a demo. The inline mode mixing text and interactive UI is where this gets interesting for data storytelling.

This is the most lucid articulation of the opportunity I've seen. The value is shifting from the workflow itself to the institutional knowledge graph the workflow generates. This is especially acute for design and strategy firms, where the 'why' behind a decision is the core asset but has always been ephemeral. We've been building a context graph for this exact problem for two years. The goal is an agent-native OS where institutional knowledge doesn't just get recorded, it compounds.

This is the right direction. The compounding loop gets even more powerful when the knowledge base isn't flat, but has pace layers. A slow-changing graph of core institutional knowledge—identity, principles, SOPs—provides durable rails for the faster-moving knowledge agents generate project by project. That's how you build unique institutional intelligence, not just a smarter wiki.

The harness-as-product framing is right. What I've found building this for design teams: the memory pillar is the hardest to get right. Flat files degrade fast. You need a structured knowledge graph underneath, with real entity types and validation, so the context the agent reads next session is actually better than what it wrote last session.

Every project your team ships makes the next one easier. Not because people remember, but because the knowledge graph does. The left side is month one. The right side is month twelve.

Design engineering skills for agents are a good start. The next step is the organizational layer underneath. Your component conventions, your naming patterns, your past decisions about when to use animation vs. static transitions. That context lives in the team, not the blog. The skill file becomes a lot more powerful when it can reference a structured history of what you've actually shipped. x.com/emilkowalski/status/20…

Most teams store what they know in documents. Meeting notes, project briefs, strategy decks. The AI searches them and returns chunks of text. It works, but the AI is doing retrieval, not reasoning. The shift is storing knowledge as typed entities with explicit relationships. A project links to its client, its team, its decisions, its research. An agent can traverse from a brief to the design principles that informed it to the client feedback that changed it. Documents give you search. A graph gives you understanding.

This is the coordination layer agents have been missing. Tried it this weekend. The next unlock is shared organizational memory with agents that know what the company knows, not just what they're told to do.

Give an AI your project files and it generates decent work. Give it a structured graph of your clients, projects, decisions, and team relationships, and it starts doing things you didn't ask for. It catches when your new scope contradicts what you told the same client last quarter. It pulls up a reference from a past project that nobody on the team thought to look for. The difference is memory.

Ran an exercise with our team recently. Took a complex project we finished last year and tried to reconstruct the decision history from our files. Figma had the artifacts. Slack had fragments. Nobody's notes had the full picture. The knowledge that made the work good lived entirely in people's heads. That's a fragile way to run a practice.

Every design tool now has an AI button. Most of them generate surfaces. Layouts, mockups, variations. The part nobody is solving well is memory. The AI has no idea what you decided last week, what your system looks like, or why you made the choices you did. Generation without context is just sophisticated randomness.