1) The way basic non-MCP tool use works is that the client (e.g. agent) registers (advertises) the tools it wants to make available to the model by sending an appropriate chunk of JSON to the model as part of every request (since the model is stateless), and if the model wants to use the tool then it'll generate a corresponding tool call chunk of JSON in the output.

2) For built-in tools like web_search the actual implementation of the tool will be done server-side before the response is sent back to the client. The server sees the tool invocation JSON in the response, calls the tool and replaces the tool call JSON with the tool output before sending the updated response back to the client.

3) For non-built-in tools such as the edit tool provided by a coding agent, the tool invocation JSON will not be intercepted server-side, and is instead just returned as-is to the client (agent) as part of the response. The client now has the responsibility of recognizing these tool invocations and replacing the invocation JSON with the tool output the same as the server would have done for built-in tools. The actual "tool call" can be implemented by the client however it likes - either internal to the client to by calling some external API.

4) MCP tools work exactly the same as other client-provided tools, aside from how the client learns about them, and implements them if the model chooses to use them. This all happens client side, with the server/model unaware that these client tools are different from any others it is offering. The same JSON tool registration and JSON tool call syntax will be used.

What happens is that client configuration tells it what MCP servers to support, and as part of client initialization the client calls each MCP server to ask what tools it is providing. The client then advertises/registers these MCP tools it has "discovered" to the model in the normal way. When the client receives a tool call in the model response and sees that it is an MCP provided tool, then it knows it has to make an MCP call to the MCP server to execute the tool call.

TL/DR

o the client/agent talks standard MCP protocol to the MCP servers

o the client/agent talks model-specific tool use protocol to the model

Actually he did, or something very close to it.

Obviously SOMETIMES you can add more developers to a project to successfully speed it up, but Brooks point was that it can easily also have the opposite effect and slow the project down.

The main reason Brooks gives for this is the extra overhead you've just added to the project in terms of communications, management, etc. In fact increasing team size always makes the team less efficient - adds more overhead, and the question is whether the new person added adds enough value to offset or overcome this.

Most experienced developers realize this intuitively - always faster to have the smallest team of the best people possible.

Of course some projects are just so huge that a large team is unavoidable, but don't think you are going to get linear speedup by adding more people. A 20 person team will not be twice as fast as a 10 person team. This is the major point of the book, and the reason for the title "the mythical man month". The myth is that men and months can be traded off, such that a "100 man month" project that would take 10 men 10 months could therefore be accomplished in 1 month if you had a team of 100. The team of 100 may in fact take more than 10 months since you just just turned a smallish efficient team into a chaotic mess.

Adding an AI "team member" is of course a bit different to adding a human team member, but maybe not that different, and the reason is basically the same - there are negatives as well as positives to adding that new member, and it will only be a net win if the positives outweigh the negatives (extra layers of specifications/guardrails, interaction, babysitting and correction - knowing when context rot has set in and time to abort and reset, etc).

With AI, you are typically interactively "vibe coding", even if in responsible fashion with specifications and guardrails, so the "new guy" isn't working in parallel with you, but is rather taking up all your time, and now his/its prodigious code output needs reviewing by someone, unless you choose to omit that step.

The machine code that actually runs on NVidia and AMD GPUs respectively are SASS and AMDGCN, and in each case there is also an intermediate level of representation:

CUDA -> PTX -> SASS

ROCm -> LLVM-IR -> AMDGCN

The Triton compiler isn't generating CUDA or ROCm - it generates it's own generic MLIR intermediate representation, which then gets converted into PTX or LLVM-IR, with vendor-specific tools then doing the final step.

If you are interested in efficiency and wanted to write high level code, then you might be using Pytorch's torch.compile, which then generates Triton kernels, etc.

If you really want to squeeze the highest performance out of an NVIDA GPU then you would write in PTX assembler, not CUDA, and for AMD in GCN assembler.

I would guess that lack of standardization of what tools are provided by different agents is as much of a problem as the differences in syntax, since the ideal case would be for a model to be trained end-to-end for use with a specific agent and set of tools, as I believe Anthropic do. Any agent interacting with a model that wasn't specifically trained to work with that agent/toolset is going to be at a disadvantage.

CEOs are laying off because of AI because they think it will save them money, but are doing so based on misinformation, largely due their own insistence that everyone uses AI, and report how much they are using - they are just hearing what they asked to hear (just like Mao hearing about impossible levels of rice production during the "Great Leap Forward"). I'm not making this up - I've seen it first hand.

You can see the proof of this - companies laying of because of what they mistakenly believe AI can do - in companies like Salesforce, forced to do an embarassing U-turn and hire people back when the reality sets in. At least Salesforce were quick to correct - most big companies are not so nimble or ready to admit their own mistakes.

We seem to have reached mania-like levels of rice-production reporting, with companies like Meta now taking AI token usage as a proxy for productivity and/or a measure of something positive, and apparently having a huge leaderboard displaying who is using the most (i.e. spending the most money!). The only guaranteed outcome of this is that they will indeed see massive use of tokens, and a massive AI bill, and then in a year or so will likely be left scratching their heads wondering why nothing much appears to have changed.

I think this is far from the truth. In many companies AI has become a religion, not a new technology to be evaluated and judged. Employees are told to use AI, and report how much they are using, and all understand the consequences of giving the wrong answer. The CEO hears the tales of rampant AI use and productivity that he is demanding to hear, then pats himself on the back and initiates another layoff. Meanwhile in the trenches little if anything has actually changed.

I guess it could happen, but that depends on your mental model when coding - if you're just pattern matching similar chunks of code (which are not being used in a semantically identical way) then all bets are off, although that seems a very alien concept of how someone might code.

OTOH, if you have a higher level mental model of what you are doing then it's not a matter of "this looks like common code" but rather "i need to do the exact same operation" (same inputs/outputs/semantics) here. Maybe I'm expressing it poorly, but I can't recall ever having to fork a function because requirements at two call sites just diverged.

I'm really talking about manually writing code, but the same would apply for AI written code. Having a single place to update when something needs changing is always going to be less error prone.

The major concession I make to modularity when developing a prototype is often to put everything into a single source file to make it fast to iteratively refactor etc rather than split it up into modules.

A third time, with a new abstraction, is where you need to be careful. Fred Brooks ("Mythical Man Month") refers to it as the "second-system effect" where the confidence of having done something once (for real, not just prototype) may lead to an over-engineered and unnecessarily complex "version 2" as you are tempted to "make it better" by adding layers of abstractions and bells and whistles.

It'd make more sense to me to have different products/brands/advertising for different market segments. For the meat eaters the marketing would be "healthy/cheap, tastes just like beef/chicken" (which seems to be what Beyond Meat are going for), and for the vegetarians "delicious flavors, plant based, high in protein" (not "fake beef").

The electoral college system, coupled with it's winner-takes-all implementation in most states, means that voting is a sham for 80% of the population. The other 20% live in a swing state and their vote can at least potentially affect the outcome of an election, but even there "your vote" will literally be cast opposite to what you put on the ballet unless you end up being part of the winning majority.

https://worldpopulationreview.com/country-rankings/happiest-...

Clearly other countries are doing something to keep their citizens happy that the US is not copying.

Given that US politics and policy is driven by lobbyists and tribal infighting, would you really expect anything different?

It's also noteworthy that Anthropic attributes Mythos' improvement to advances in "coding, reasoning and autonomy", and that the autonomy part seems especially important since they go on to say that trying to develop exploits included adding debug code to projects, running them under a debugger, etc.

When comparing the capabilities of Mythos to previous generation and/or smaller models, it seems it would therefore be useful to distinguish between identifying potential vulnerabilities and actually trying to build exploits for them in agentic fashion. Finding the "needle in a haystack" (potential vulnerability) is one aspect, but the other part is an agentic exploit-writing harness being handed the needle and asked to try to exploit it.

I wonder how much effort Anthropic put into building the harnesses and environments for Mythos to run, modify and debug code? For example, was Mythos set up to be able to build and run a modified BSD in some virtual environment, or did it just take suspect functions and test those in isolation?

It'd be interesting to put the capabilities of Opus 4.6, Mythos, and other models into perspective by comparing them to traditional non-AI static analysis security scanning tools. Anthropic mention that the open source projects they scanned came from the OSS-Fuzz corpus, but as far as I can see they don't say what other tools have, or have not, been used to scan these projects.

It'd also be interesting to know to what extent Mythos was explicitly RL trained to develop exploits (especially since it sounds as if Anthropic have the dataset and environment needed to do this) as opposed to this just being a natural consequence of the model being better. If this was the case then it might be a large part of why they are not releasing it - can't really position yourself as strong on security if you deliberately develop and release a hacking tool!