Those who succeeded at SEO are the same who will (and arguably, are) succeeding at AEO/GEO/AIO or whatever we want to call it. And more over, AEO has been gamed with false pretence of authority by hijacking influence via 'prestigious' channels - demonstrated with false attribution, press releases, reddit astroturfing or numerous other vectors. These are arguably the same techniques of early SEO, moral or not, by showing up and acting up in places one assumes authority comes from.
I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...
Yes and no -- you can give internal agents access to internal APIs by using rudimentary env var, and org level agentic services tend to offer that kind of permission based access (either roll your own, use an 'enterprise' service, or be knowledgeable that if things go wrong, they'll go very wrong). APIs should, at least from my perspective, always have permission mechanisms. But internal APIs, used by 'internal' agents, have access to those the same way users on the network do, just depends on what flavour of network one is using.
Essentially it's anything that _could_ be on a dashboard, but _might_ be accessed conversationally via an agent.
hadn't heard of runlayer, but it does make sense. I'm a huge advocate of skills based on the company/process or project owners perspectives and workflow habits rather than using skills.sh or similar. You will end up cosplaying as someone elses perspective and wonder why you don't understand it..
I've dabbled a few times in writing bitmap font parsers for both technically constrained and artistic projects. There is a reason that design has resolved to the same few cliches, because expectability, latent understanding, and 'obviousness' reduces onboarding curve and fatigue. It's a cognitive accessibility issue before you even get to legitimate accessibility concerns. Render a .F16 at anything larger than 16px in a modern application and you're introducing issues which are solved, quantitatively and qualitatively, by vector graphics and antialiasing. There's an optimistic naivety which is nice to have, but misunderstands design as a conduit for informed action vs design as an aesthetic function independent of intent is legitimately dangerous if you're doing anything other than building narrative products emulating older tech.
Something I've been tinkering on for the last few weeks is absent.dev[1], was working towards getting the guts to share this on HN but there's a few things I want to polish first. This is the MVP, but it will essentially be moving towards what you're suggesting, much more customisable news aggregation and more importantly, where you consume it. Feed agnostic, channel agnostic, in the form(s) you want (longform, shortform, summary, tl;dr etc). You can check the clustering logic on the digest[2].
I think that the inverse thesis is true, you make websites more accessible (a11y, wgac, aria labels etc) for humans, then the interaction heuristics are clearer for agents functioning off browser-use or similar. If a screen reader can understand your site, then an agent can. Reinventing the wheel to facilitate the current state of agents makes the web worse for everyone, it's not a preemptive move, it's actually a decline in almost objective and measurable quality, and potentially one which removes access to the internet by people who just want to.. use the internet.
This. The accessibility tree is a superpower for agents when it's good. Screenshots are "robust" but low performance. Like so many other things, making stuff better for humans indirectly makes it better for agents.
