Kimi K2 Thinking is built for advanced chain-of-thought reasoning, which makes it a strong fit for any workflow that needs structured analysis instead of surface-level answers. In this tutorial, I will walk through building a Deep Research Analyst agent that decomposes complex topics, weighs competing perspectives, and generates a structured markdown report. We will run the whole thing on Oxlo.ai, where request-based pricing keeps costs flat even when we stuff the context window with long source material.
What you'll need
- Python 3.10 or newer
- The OpenAI SDK:
pip install openai - An Oxlo.ai API key from https://portal.oxlo.ai
If you are new to Oxlo.ai, the Free plan includes a 7-day full-access trial, so you can test kimi-k2-thinking without upfront cost. See the pricing page for plan details.
Step 1: Configure the Oxlo.ai client
First, I initialize the OpenAI-compatible client pointing at Oxlo.ai and select kimi-k2-thinking. This model exposes its chain-of-thought reasoning, which is exactly what we want for a research agent.
from openai import OpenAI
client = OpenAI(
base_url="https://api.oxlo.ai/v1",
api_key="YOUR_OXLO_API_KEY"
)
MODEL = "kimi-k2-thinking"Step 2: Define the system prompt
The system prompt is the most important part of this build. I force the model to decompose the topic, explore multiple hypotheses, and expose its reasoning before it states any conclusion.
SYSTEM_PROMPT = """You are a Deep Research Analyst powered by advanced chain-of-thought reasoning.
When you receive a research topic, perform the following internal reasoning steps before producing output:
1. Decompose the topic into 3 to 5 concrete sub-questions that must be answered to fully address the topic.
2. For each sub-question, explore at least two competing hypotheses or perspectives, noting evidence for and against each.
3. Identify key uncertainties, confounders, or gaps in the information.
4. Synthesize your analysis into a final structured report.
Output format:
- EXECUTIVE SUMMARY: One paragraph with the bottom-line answer.
- KEY FINDINGS: A section for each sub-question with your reasoning and conclusion.
- OPEN QUESTIONS: Bullet list of what remains uncertain.
Be explicit about your reasoning. Do not skip steps."""Step 3: Build the analysis function
Next, I wrap the API call in a simple function. I keep the temperature low at 0.2 because research analysis benefits from consistency, not randomness.
from openai import OpenAI
client = OpenAI(
base_url="https://api.oxlo.ai/v1",
api_key="YOUR_OXLO_API_KEY"
)
MODEL = "kimi-k2-thinking"
SYSTEM_PROMPT = """You are a Deep Research Analyst powered by advanced chain-of-thought reasoning.
When you receive a research topic, perform the following internal reasoning steps before producing output:
1. Decompose the topic into 3 to 5 concrete sub-questions that must be answered to fully address the topic.
2. For each sub-question, explore at least two competing hypotheses or perspectives, noting evidence for and against each.
3. Identify key uncertainties, confounders, or gaps in the information.
4. Synthesize your analysis into a final structured report.
Output format:
- EXECUTIVE SUMMARY: One paragraph with the bottom-line answer.
- KEY FINDINGS: A section for each sub-question with your reasoning and conclusion.
- OPEN QUESTIONS: Bullet list of what remains uncertain.
Be explicit about your reasoning. Do not skip steps."""
def analyze_topic(topic: str) -> str:
response = client.chat.completions.create(
model=MODEL,
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": f"Research topic: {topic}"},
],
temperature=0.2,
max_tokens=4000,
)
return response.choices[0].message.contentStep 4: Add streaming for long reports
Kimi K2 Thinking can generate lengthy chain-of-thought before the final report. Streaming lets us watch the reasoning unfold in real time instead of waiting for the entire payload.
from openai import OpenAI
client = OpenAI(
base_url="https://api.oxlo.ai/v1",
api_key="YOUR_OXLO_API_KEY"
)
MODEL = "kimi-k2-thinking"
SYSTEM_PROMPT = """You are a Deep Research Analyst powered by advanced chain-of-thought reasoning.
When you receive a research topic, perform the following internal reasoning steps before producing output:
1. Decompose the topic into 3 to 5 concrete sub-questions that must be answered to fully address the topic.
2. For each sub-question, explore at least two competing hypotheses or perspectives, noting evidence for and against each.
3. Identify key uncertainties, confounders, or gaps in the information.
4. Synthesize your analysis into a final structured report.
Output format:
- EXECUTIVE SUMMARY: One paragraph with the bottom-line answer.
- KEY FINDINGS: A section for each sub-question with your reasoning and conclusion.
- OPEN QUESTIONS: Bullet list of what remains uncertain.
Be explicit about your reasoning. Do not skip steps."""
def analyze_topic(topic: str, stream: bool = True) -> str:
response = client.chat.completions.create(
model=MODEL,
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": f"Research topic: {topic}"},
],
temperature=0.2,
max_tokens=4000,
stream=stream,
)
full_text = ""
for chunk in response:
delta = chunk.choices[0].delta.content or ""
full_text += delta
print(delta, end="", flush=True)
return full_textStep 5: Wire up the CLI
Finally, I add a small argument parser so I can run this from the terminal and optionally save the report to a file. This turns the script into a tool I can actually ship and use during team meetings.
import argparse
from openai import OpenAI
client = OpenAI(
base_url="https://api.oxlo.ai/v1",
api_key="YOUR_OXLO_API_KEY"
)
MODEL = "kimi-k2-thinking"
SYSTEM_PROMPT = """You are a Deep Research Analyst powered by advanced chain-of-thought reasoning.
When you receive a research topic, perform the following internal reasoning steps before producing output:
1. Decompose the topic into 3 to 5 concrete sub-questions that must be answered to fully address the topic.
2. For each sub-question, explore at least two competing hypotheses or perspectives, noting evidence for and against each.
3. Identify key uncertainties, confounders, or gaps in the information.
4. Synthesize your analysis into a final structured report.
Output format:
- EXECUTIVE SUMMARY: One paragraph with the bottom-line answer.
- KEY FINDINGS: A section for each sub-question with your reasoning and conclusion.
- OPEN QUESTIONS: Bullet list of what remains uncertain.
Be explicit about your reasoning. Do not skip steps."""
def analyze_topic(topic: str, stream: bool = True) -> str:
response = client.chat.completions.create(
model=MODEL,
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": f"Research topic: {topic}"},
],
temperature=0.2,
max_tokens=4000,
stream=stream,
)
full_text = ""
for chunk in response:
delta = chunk.choices[0].delta.content or ""
full_text += delta
print(delta, end="", flush=True)
return full_text
if __name__ == "__main__":
parser = argparse.ArgumentParser(description="Deep Research Analyst via Oxlo.ai")
parser.add_argument("topic", help="Research topic to analyze")
parser.add_argument("--output", "-o", help="Optional file path to save the report")
args = parser.parse_args()
print(f"\n--- Researching: {args.topic} ---\n")
report = analyze_topic(args.topic, stream=True)
if args.output:
with open(args.output, "w", encoding="utf-8") as f:
f.write(report)
print(f"\n\nReport saved to {args.output}")Run it
Save the script as research_agent.py and run it with a topic that demands real reasoning. Here is what I used to test the agent:
$ python research_agent.py "Trade-offs between microservices and monoliths for early-stage startups" -o report.md
--- Researching: Trade-offs between microservices and monoliths for early-stage startups ---
EXECUTIVE SUMMARY
For early-stage startups operating with small teams and rapidly shifting requirements, a modular monolith generally offers lower operational overhead and faster iteration cycles than a distributed microservices architecture. The complexity of service boundaries, deployment orchestration, and cross-team synchronization typically outweighs the scalability benefits until both engineering headcount and traffic exceed clear thresholds.
KEY FINDINGS
1. Sub-question: What are the operational costs of each architecture at small scale?
Reasoning: At low traffic, the fixed cost of orchestration, monitoring, and deployment pipelines for microservices introduces non-trivial overhead. A single deployable unit in a monolith eliminates network latency between components and reduces the surface area for failures. However, a monolith can degrade if modules are tightly coupled.
Conclusion: Monoliths require roughly one-third the infrastructure tooling effort at the 2-to-8 engineer scale.
2. Sub-question: How does team size affect the maintainability boundary?
Reasoning: Conway's Law suggests that system boundaries mirror communication boundaries. Below roughly 10 engineers, most developers touch multiple domains, so cross-service changes dominate and create synchronization overhead. Microservices shine when teams can own services end-to-end.
Conclusion: The transition point typically appears between 10 and 20 engineers, depending on product complexity.
3. Sub-question: What is the migration cost if we start with the wrong choice?
Reasoning: Extracting a service from a well-modularized monolith is a bounded refactoring task. Reversing a premature microservices split requires distributed transaction reconciliation and data re-ownership.
Conclusion: Starting with a modular monolith preserves optionality at lower risk.
OPEN QUESTIONS
- At what exact team size does the microservice decomposition payoff curve invert?
- How do serverless container platforms alter the operational cost calculus for startups with variable traffic?
- What module boundary conventions prevent a monolith from becoming a tightly coupled big ball of mud?The output above is unedited. Notice how Kimi K2 Thinking exposes its reasoning before each conclusion, which makes the report auditable and useful for technical decision-making.
Wrap-up
This agent is already useful for architecture reviews and product research, but two concrete next steps make it production-ready. First, add a retrieval step by piping long source documents into the context window, which is cost-effective on Oxlo.ai because the flat per-request pricing does not scale with input length. Second, convert the script into an async service with function calling so the agent can query a vector database or search API before it synthesizes the final report.
Top comments (0)