Compare OpenAI function calling, Anthropic tool use, and ReAct free-form text as agent tool-invocation mechanisms

An agent needs a way to tell the runtime which tool to run and with what arguments. There are three common ways to do this, and they differ a lot in how reliable they are. The first is **native function calling**, used by OpenAI and Anthropic. You register your tools with a name and a JSON schema. The model was trained to emit a structured object naming the tool and its arguments. The provider validates that object before you ever see it, so it is almost always machine-readable. The second is ReAct free-form text. Here the model writes something like "Action: search(query=cats)" inside its normal text reasoning. Your runtime then parses that string with a regex to pull out the name and arguments. This works with any model, but it breaks when the model phrases things slightly differently. The third is constrained decoding. The runtime restricts which tokens the model can produce so the output must match the schema. It cannot generate invalid JSON even if it tries. The takeaway: native calling and constrained decoding give you structure by construction, while free-form parsing is flexible but fragile.

All three are mechanisms for an agent to express a tool invocation, and they trade reliability against portability. **Native function calling** is the modern default. OpenAI returns a JSON arguments object; Anthropic returns a `tool_use` content block. In both cases the model was trained to emit the structure, and the provider validates it against your registered schema. Reliability is high because the output is parseable by construction. The tradeoff is provider lock-in. Each vendor has its own schema format, so switching means re-registering tools. ReAct free-form text is the portable option. The model writes the action in natural language inside its reasoning trace, and your runtime parses that string with a regex or grammar. It works with any instruction-following model. The tradeoff is fragility. The model can drift in phrasing, hallucinate a tool name, or emit malformed arguments, so you need a robust parser and retry logic. Constrained decoding sits underneath either approach. The decoder masks tokens so only schema-valid continuations are sampled. This guarantees well-formed output even on weaker models. The cost is a slightly more complex serving stack and occasional latency overhead. The 2026 default is native calling plus a validation layer, because trained-in structure and an explicit schema check together catch both format errors and semantically wrong arguments.