We are going to build a deep reasoning system that turns a vague technical requirement into a thoroughly reasoned architecture recommendation. If you are a tech lead who receives one-line JIRA tickets that deserve days of analysis, this pipeline gives you a structured head start in under fifty lines of Python.
What you'll need
Before we start, make sure you have the following ready.
- Python 3.10 or newer
- The OpenAI SDK installed:
pip install openai - An Oxlo.ai API key from https://portal.oxlo.ai
Oxlo.ai is fully OpenAI SDK compatible, so the only difference is the base URL and the API key.
Step 1: Instantiate the Oxlo.ai client
I keep credentials out of source control by reading from an environment variable. The client initialization is a drop-in replacement for OpenAI. Because Oxlo.ai exposes the exact same chat completions interface, you can reuse existing error handling and retry logic without changes.
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.oxlo.ai/v1",
api_key=os.getenv("OXLO_API_KEY", "YOUR_OXLO_API_KEY")
)Step 2: Define the reasoning prompts
A reliable reasoning pipeline separates concerns. I use three prompts: one to break the problem into sub-questions, one to reason deeply about each piece, and one to synthesize the results into a coherent recommendation. Treat these as editable constants you can tune for your domain.
DECOMPOSE_PROMPT = """You are a senior staff engineer. Given a vague technical requirement, break it into 3 to 5 focused sub-questions that must be answered before we can propose an architecture. Return exactly one sub-question per line, prefixed with '- '."""
REASON_PROMPT = """You are a deep reasoning engine. For the sub-question provided, state your assumptions, compare at least two viable approaches, and recommend the best option with specific trade-offs. Be thorough but concise."""
SYNTHESIZE_PROMPT = """You are a technical lead writing an architecture decision record. Given the original problem and the reasoned answers to each sub-question, produce a unified recommendation. Include a brief verdict, explicit risks, and concrete next steps."""Step 3: Decompose the problem
The first stage turns a messy brief into a checklist of focused investigations. I use qwen-3-32b here because it follows instructions precisely and returns clean output. The model receives the raw problem statement and returns a bullet list. We parse that into a Python list so the rest of the pipeline can iterate over each item independently.
def decompose(problem: str) -> list[str]:
response = client.chat.completions.create(
model="qwen-3-32b",
messages=[
{"role": "system", "content": DECOMPOSE_PROMPT},
{"role": "user", "content": problem},
],
)
text = response.choices[0].message.content
return [line.strip("- ").strip() for line in text.splitlines() if line.strip().startswith("-")]Step 4: Reason through each sub-question
This is where the depth happens. I route each sub-question to deepseek-v3.2, which handles complex reasoning and coding contexts well. The prompt forces explicit assumptions and trade-off analysis, so you get an audit trail rather than a black box answer. Because Oxlo.ai uses flat per-request pricing, the long reasoning traces typical of deep reasoning models do not inflate your bill the way token-based metering would. You pay one flat cost per call, which makes multi-step pipelines predictable. That matters when a single reasoning step can emit several thousand tokens of chain-of-thought.
def reason(sub_question: str) -> str:
response = client.chat.completions.create(
model="deepseek-v3.2",
messages=[
{"role": "system", "content": REASON_PROMPT},
{"role": "user", "content": sub_question},
],
)
return response.choices[0].message.contentStep 5: Synthesize the final recommendation
Raw reasoning is useful to engineers, but stakeholders want a single narrative. I feed every sub-answer into llama-3.3-70b with a synthesis prompt that asks for a unified verdict. The result is a document you can paste directly into an architecture decision record or a Slack thread. I prefer llama-3.3-70b for this stage because it produces well-structured markdown and keeps the tone professional without excessive verbosity.
def synthesize(problem: str, answers: list[str]) -> str:
context = f"Original problem: {problem}\n\n"
for i, ans in enumerate(answers, 1):
context += f"--- Sub-question {i} reasoning ---\n{ans}\n\n"
response = client.chat.completions.create(
model="llama-3.3-70b",
messages=[
{"role": "system", "content": SYNTHESIZE_PROMPT},
{"role": "user", "content": context},
],
)
return response.choices[0].message.contentRun it
Here is the complete entry point. I will use a real scenario I faced last quarter: migrating a large PostgreSQL cluster to a multi-region setup with tight latency requirements and a limited budget. When you execute the script, the pipeline makes one decomposition call, one reasoning call per sub-question, and one synthesis call. On Oxlo.ai, that is four flat requests. There are no cold starts, so the entire run finishes in seconds.
def deep_reason(problem: str) -> str:
sub_questions = decompose(problem)
answers = [reason(q) for q in sub_questions]
return synthesize(problem, answers)
if __name__ == "__main__":
problem = (
"We need to migrate a 10 TB PostgreSQL cluster to a multi-region setup "
"with sub-100ms read latency. Budget is tight."
)
report = deep_reason(problem)
print(report)When I run this, the output looks something like the following.
## Recommendation
Keep the primary PostgreSQL instance in the original region and deploy asynchronous read replicas in the target regions. Route read traffic through PgBouncer with regional connection pooling to stay under the latency target without the cost of a full distributed SQL rewrite.
## Risks
- Asynchronous replication introduces replication lag. If the application requires strongly consistent reads cross-region, this architecture will fail.
- Initial seeding of 10 TB across regions will take significant time. Plan for logical replication or a physical base backup shipped out of band.
## Next Steps
1. Run a pgbench or simple psql latency test from each target region to validate the 100ms ceiling.
2. Audit the application for cross-region write dependencies before committing to async replicas.
3. Estimate egress costs for replication traffic and compare against managed database offerings on Oxlo.ai.Wrap-up and next steps
This pipeline gives you a reproducible way to force structure onto ambiguous problems. Two concrete ways to extend it. First, add streaming so you can watch each reasoning stage unfold in real time. Oxlo.ai supports streaming on all chat models, so you only need to pass stream=True in each completion call and iterate over the chunks. This is useful for long-running synthesis steps where you want to show progress in a UI. Second, store the intermediate traces in SQLite or append them to a Notion database. The reasoning trail is often more valuable than the final summary because it captures why a decision was made, not just what the decision is. When you revisit the project in six months, the rationale saves you from re-deriving the same conclusions.
If you are building agentic workflows that chain multiple model calls, Oxlo.ai's request-based pricing keeps costs flat regardless of how verbose your deep reasoning traces become. You can explore the details at https://oxlo.ai/pricing and start building with the free tier.
