Kimi as an Agent: Browsing, Tools, and Multi-Step Tasks

Modern Kimi variants ship with first-class tool calling, web browsing inside the chat product, and structured output modes. The platform is moving in the same direction as OpenAI and Anthropic: less 'answer the question' and more 'do the task end to end'. The patterns you already know from those ecosystems carry over almost perfectly.

Function calling on Moonshot's API

tools = [
    {
        "type": "function",
        "function": {
            "name": "lookup_invoice",
            "description": "Find an invoice by ID in the internal billing system.",
            "parameters": {
                "type": "object",
                "properties": {
                    "invoice_id": {"type": "string"}
                },
                "required": ["invoice_id"],
            },
        },
    }
]

resp = client.chat.completions.create(
    model="<long-context-model-id>",
    messages=messages,
    tools=tools,
    tool_choice="auto",
)

Where Kimi's agents shine

• Research assignments that require reading a stack of uploaded files plus a few web sources
• Bilingual research tasks where Chinese-language sources matter
• Tasks where the long context lets the agent skip a retrieval step entirely

Where it still feels rough

• Long agent loops sometimes drift in tone after many turns — anchor with explicit goal restatement
• Tool-error handling is less battle-tested than mature Western SDKs
• Observability tooling around the API is thinner; build your own logging early

Apply this

1. 1Define a small two-tool agent task (lookup + email-draft, for example)
2. 2Implement it on Moonshot's function-calling API and on one Western API
3. 3Compare reliability, latency, and how each handles a deliberately broken tool response

The big idea: Kimi is now an agent platform, not just a chat model. The patterns you already know about agent reliability port directly — and the rough edges are mostly around tooling, not the model itself.