Live data from Hacker News

Designing APIs for Agents

freestyle.sh

1–10 of 58 posts

Re: Designing APIs for Agents

#5
>Defaults are bad. Agents can be expected to read the documentation, register what good starting values are, and fill them all in, in place.

This is not what defaults are for.

If, for example, you are writing a replacement CLI for git, *for the love of God and all that is holy* do not force agents to read the entire documentation and pass a value for every possible parameter

Re: Designing APIs for Agents

#6
post #4

First time I'm hearing about https://agentauthprotocol.com/ and https://workos.com/auth-md MCP and A2A weren't enough?

MCP Auth is just Oauth, its designed for humans to authenticate their sessions for connections.

TBH I know nothing about A2A.

Agent Identity and Authz is a different problem, allowing agents to operate independently from humans with granular permissions is coming/whether from these protocols or others, and when it does I think CLIs/CLI Device Auth which is used as a rough proxy for this where the agent just takes your identity will finally go away.

Re: Designing APIs for Agents

#7

>Defaults are bad. Agents can be expected to read the documentation, register what good starting values are, and fill them all in, in place. This is not what defaults are for. If, for example, you are writing a replacement CLI for git, *for the love of God and all that is holy* do not force agents to read the entire documentation and pass a value for every possible parameter

Why not?

The docs for git clone at https://git-scm.com/docs/git-clone are less than 4000 tokens, I don't think this is unreasonable.

Re: Designing APIs for Agents

#8
post #7

>Defaults are bad. Agents can be expected to read the documentation, register what good starting values are, and fill them all in, in place. This is not what defaults are for. If, for example, you are writing a replacement CLI for git, *for the love of God and all that is holy* do not force agents to read the entire documentation and pass a value for every possible parameter

Why not? The docs for git clone at https://git-scm.com/docs/git-clone are less than 4000 tokens, I don't think this is unreasonable.

Because the defaults aren't just for convenience, the API designer is also making the parameters they think should be used the most have the least resistance. Good example is runtime parameters like in the JVM. You shouldn't start with having to tune your JVM, you probably want a middle of the road place to start with even if you know you're going to tune it.

Re: Designing APIs for Agents

#9
post #7

>Defaults are bad. Agents can be expected to read the documentation, register what good starting values are, and fill them all in, in place. This is not what defaults are for. If, for example, you are writing a replacement CLI for git, *for the love of God and all that is holy* do not force agents to read the entire documentation and pass a value for every possible parameter

Why not? The docs for git clone at https://git-scm.com/docs/git-clone are less than 4000 tokens, I don't think this is unreasonable.

Because LLMs degrade with context length. And even if they didn't, having to constantly ingest the same stuff is wasteful for execution and cost. Why stuff the context when you don't have to?

Re: Designing APIs for Agents

#10
post #9
post #7

Earlier quoted context omitted.

Why not? The docs for git clone at https://git-scm.com/docs/git-clone are less than 4000 tokens, I don't think this is unreasonable.

Because LLMs degrade with context length. And even if they didn't, having to constantly ingest the same stuff is wasteful for execution and cost. Why stuff the context when you don't have to?

Conservatively speaking, LLMs degrade past 40% of a 2M context window, 4k tokens is 0.2%, so no degradation there. Thats also current generation conservative estimate.

I think wasteful is an irrelevant metric. Claude ingests those tokens in a quarter of a second, if it causes it to catch any bug ever it saves far more time than it ever uses.

Any individual default that causes unexpected behavior causes more problems, takes more time and costs more than the small cost of being explicit.

Post reply on HN