I wonder if append-only will continue to be important. As agents get more powers, their actions will likely be the bottleneck, not the LLM itself. And at n*2, recomputing a whole new context might not take much longer than just computing the delta, or even save time if the new context is shorter.
Context engineering is sleeping on the humble hyperlink
61–69 of 69 posts
Re: Context engineering is sleeping on the humble hyperlink
#62Earlier quoted context omitted.
Deriving a presentation layer from an API definition has no bearing on whether the client has to be stateful or not. The key difference for 'true' HATEOAS is that the API schema is sufficiently descriptive that the client does not need to request any presentation layer; arguably not even HTML, but definitely not CSS or JavaScript. https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st... > any concept that migh…
Dude, he literally mentions Java Applets as an example (it was popular back then, if it was written today it would have been JavaScript). It's all there. Section 5.1.7. It's an optional constraint. It's valid for CSS, JavaScript and any kind of media type that is negotiable. > resource: the intended conceptual target of a hypertext reference > representation: HTML document, JPEG image A resource is abstract . You alw…
I will concede the thrust of my argument probably does not fully align with Fielding's academic definition, so thank you for pointing me to that and explaining it a bit.
I'm realizing/remembering now that our internal working group's concept of HATEOAS was, apparently, much stricter to the point of being arguably divergent from Fielding's. For us "HATEOAS" became a flag in the ground for defining RESTful(ish) API schemas from which a user interface could be unambiguously derived and presented, in full with 100% functionality, with no HTML/CSS/JS, or at least only completely generic components and none specific to the particular schema.
Re: Context engineering is sleeping on the humble hyperlink
#63Earlier quoted context omitted.
Dude, he literally mentions Java Applets as an example (it was popular back then, if it was written today it would have been JavaScript). It's all there. Section 5.1.7. It's an optional constraint. It's valid for CSS, JavaScript and any kind of media type that is negotiable. > resource: the intended conceptual target of a hypertext reference > representation: HTML document, JPEG image A resource is abstract . You alw…
I will concede the thrust of my argument probably does not fully align with Fielding's academic definition, so thank you for pointing me to that and explaining it a bit. I'm realizing/remembering now that our internal working group's concept of HATEOAS was, apparently, much stricter to the point of being arguably divergent from Fielding's. For us "HATEOAS" became a flag in the ground for defining RESTful(ish) API sch…
It happens.
"Schema" is also foreign to REST. That is also a requirement coming from somewhere else.
You're probably coming from a post-GraphQL generation. They introduced this idea of sharing a schema, and influenced a lot of people. That is not, however, a requirement for REST.
State is the important thing. It's in the name, right? Hypermedia as the engine of application state. Not application schema.
It's much simpler than it seems. I can give a common example of a mistake:
GET /account/12345/balance GET /my/balance In the second example, the concept of resource is being corrupted. It means something from some users, and something to others, depending on state.
In the first example, the hypermedia drives the state. It's in the link (but it can be on form data, or negotiation, for example, as long as it is stateless).
There is a little bit more to it, and it goes beyond URI design, but that's the gist of it.
It's really simple and not that academical as it seems.
Fielding's work is more a historical formalisation where he derives this notion from first principles. He kind of proves that this is a great style for networking architectures. If you read it, you understand how it can be performant, scalable, fast, etc, by principle. Most of the dissertation is just that.
Re: Context engineering is sleeping on the humble hyperlink
#64Earlier quoted context omitted.
That article appears to be very confused about how skills work. It seems to think they are a vendor lockin play by Anthropic, running as an opaque black box. To rebut their four complaints: 1. "Migrating away from Anthropic in the future wouldn't just mean swapping an API client; it would mean manually reconstructing your entire Skills system elsewhere." - that's just not true. Any LLM tool that can access a filesyst…
This isn't an accurate take either. You can load client skills, sure, but the whole selling point from Anthropic is that skills are like memory, managed at the API layer "transparently" and that those skills are cross project. If you forced Claude to only use skills from the current project to try and be transparent, it would still be a black box that makes it harder to debug failures, and it'd still be agent and ven…
Skills are just lazy loaded prompts. The system prompt will include the summary of every skill, and if the LLM decides it want to use a specific skill the details of that skill will be added to the system prompt. It's just markdown documents all the way down.
Re: Context engineering is sleeping on the humble hyperlink
#65isn't this basically rag with a different entrypoint? following links works when the corpus is well-authored/ hierarchical but most real data isn't. how do you handle relevance ranking/stale links/huge fan-out?? "just follow hyperlinks" can blow up the context window just as easily
Re: Context engineering is sleeping on the humble hyperlink
#66Earlier quoted context omitted.
Altering the presentation layer is possible precisely because HTML is a semantic API definition: one broad enough to enable self-description across a variety of domains, but specific enough that those applications can still be re-contextualized according to the user's needs and preferences.
Your point would be much stronger if all web forms were served in pure HTML and not 95% created by JS SPAs.
I think the web itself would be stronger if it was served in pure HTML and not 95% created by JS SPAs.
Re: Context engineering is sleeping on the humble hyperlink
#67Earlier quoted context omitted.
Yes, which is exactly true of the Web. There is no aspect of a web page that is not derived from the HTML+JS+CSS files served by a server.
...which are a presentation layer and not a semantic, RESTful API definition.
No, they are a semantic layer for the browser-server communication. They encapsulate human-readable content in a machine interpretable definition.
Re: Context engineering is sleeping on the humble hyperlink
#68Earlier quoted context omitted.
I think you are confusing the browser with the web page. You probably think that the Javascript code executed by your browser is part of the "client" in the REST architecture - which is simply not what we're talking about. When analyzing the WWW, the REST API interface is the interface between the web browser and the web server, i.e. the interface between, say, Safari and Apache. The web browser accesses a single end…
I'm not confusing it. I was heavily motivated by business goals to find a general solution for HATEOAS-ifying API definitions. And yes, a web page, implemented in HTML/CSS/JS is a facsimile for it in a certain sense, but it's not self-contained RESTful API definition.
Again, you're talking about a particular web page, when I'm talking about the entire World Wide Web. The API of the WWW is indeed a RESTful API, driven entirely by hyperlinks. You can consider the WWW as a single service in this sense, where there is a single, and your browser is a client of that service. The API of this service is described in the HTTP RFCs and the WHATWG living standard for HTML, and the ECMAScript standard.
Say I as a user want to read the latest news stories of the day in the NYT. I tell my browser to access the NYT website root address, and then it contacts the server and discovers all necessary information for achieving this task on its own. It may choose to present this information as a graphical web page, or as a stream of sound, all without knowing anything about the NYT web site a priori.
Re: Context engineering is sleeping on the humble hyperlink
#69Earlier quoted context omitted.
The Web is not only true HATEOAS, it is in fact the motivating example for HATEOAS. Roy Fielding's paper that introduced the concept is exactly about the web, REST and HATEOAS are the architecture patterns that he introduces primarily to guide the design of HTTP for the WWW. The concept of a HATEOAS API is also very simple: the API is defined by a communication protocol, 1 endpoint, and a series of well-defined media…
It's a broader definition of HATEOAS. A stricter interpretation with practical, real-world benefits is a RESTful API definition that is fully self-contained that the client can get in a single request from the server and construct the presentation layer in whole with no further information except server responses in the same format. Or, slightly less strictly, a system where the server procedurally generates the pres…
It is the original definition from Roy Fielding's paper. Arguably, you are talking about a more specific notion than the full breadth of what the HATEOAS concept was meant to inform.
The point of HATEOAS is to inform the architecture of any system that requires numerous clients and servers to interoperate with little ability for direct cooperation; and where you also need the ability to evolve this interaction in the longer term with the same constraint of no direct cooperation. As the dissertation explains, HATEOAS was used to guide specific fixes to correct mistakes in the HTTP/1.0 standard that limited the ability to achieve this goal for the WWW.