This part covers the remaining domains and how to register for the exam. Here is what we will cover.

1. Prompt Engineering & Structured Output

2. Context Management & Reliability

3. How to register for the exam

I have also added more practice questions to the CCAF GitHub repo. Six sets now, covering all domains.

1. Prompt Engineering & Structured Output

• Explicit Criteria

• Few-shot Prompting

• Structured Output

• Validation-Retry Loops

• Multi-pass Review

• Schema Design

Explicit Criteria

We have to give exact instructions to Claude instead of vague conditions. This is called explicit criteria. Telling Claude like “be careful” or “report high security issues” does not work. Claude does not know what that means in practice.

Tell Claude exactly what to do and what not to do. When you are more specific, Claude makes fewer mistakes.

# Bad — vague, 
system_prompt = """
Review this code and flag any security issues.
Only report high confidence findings.
"""

# Good — categorical, Claude knows exactly what to flag
system_prompt = """
Review this code for security issues.
Flag a finding ONLY when:
- User input is passed directly to a SQL query without parameterization
- A secret or API key is hardcoded as a string literal
- User-supplied data is rendered in HTML without escaping

Do not flag theoretical risks or best practice suggestions.
"""

Few-shot Prompting

Give Claude examples before asking it to do the task. This is called few-shot prompting. Two to four examples is enough. More than that wastes tokens.

One thing to keep in mind. Few-shot prompting is probabilistic. Claude will follow the examples most of the time but not always. If you want something to run without fail, put it in a hook.

system_prompt = """
Extract the customer name and order ID from the message below.

Example 1:
Message: "Hi, I am John and my order 1234 has not arrived."
Output: {"name": "John", "order_id": "1234"}

Example 2:
Message: "This is Sarah. Order #5678 is damaged."
Output: {"name": "Sarah", "order_id": "5678"}

Now extract from this message:
"""

Structured Output

If you ask Claude to “output as JSON” in the prompt, it will try. But it is not guaranteed. The reliable way is to use structured outputs.

Method 1 — JSON outputs

• Define the schema in output_config of the client.messages.create() call.

• Claude returns the answer as JSON text in response.content[0].text.

• Parse it with json.loads() to get the data.

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Extract order details from: John's order 1234 is missing"}],
    output_config={ # tells Claude to return structured JSON
        "format": {
            "type": "json_schema",
            "schema": {
                "type": "object",
                "properties": {
                    "customer_name": {"type": "string"},
                    "order_id": {"type": "string"},
                    "issue": {"type": "string"}
                },
                "required": ["customer_name", "order_id", "issue"]
            }
        }
    }
)
# Claude returns guaranteed JSON in content[0].text
result = json.loads(response.content[0].text)
# {"customer_name": "John", "order_id": "1234", "issue": "missing"}

Method 2 — Strict tool use

This method is used to pass structured input to your tools with guaranteed schema compliance.

When Claude calls a tool in an agentic workflow, it passes parameters to that tool. Without strict mode, those parameters may not match your schema exactly. With strict: True on the tool definition, Claude is forced to pass parameters that exactly match your input_schema. The structured data Claude fills in is available in block.input on the tool call response.

tools = [{
    "name": "extract_order",
    "description": "Extract order details",
    "strict": True,          # Claude must fill in all fields exactly as defined
    "input_schema": {
        "type": "object",
        "properties": {
            "customer_name": {"type": "string"},
            "order_id": {"type": "string"},
            "issue": {"type": "string"}
        },
        "required": ["customer_name", "order_id", "issue"]
    }
}]

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    tools=tools,
    tool_choice={"type": "tool", "name": "extract_order"},  # force Claude to call this tool
    messages=[{"role": "user", "content": "John's order 1234 is missing"}]
)

for block in response.content:
    if block.type == "tool_use":
        print(block.input)   # structured data Claude filled in
        # {"customer_name": "John", "order_id": "1234", "issue": "missing"}

Validation-Retry Loops

Structured output guarantees the structure. It does not guarantee the values are correct. This is where the validation-retry loop comes in. When Claude returns wrong values, you send the error back with specific details about what went wrong. Claude fixes it and tries again.

MAX_RETRIES = 3
for attempt in range(MAX_RETRIES):
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        tools=tools,
        tool_choice={"type": "tool", "name": "extract_order"},
        messages=messages
    )

    for block in response.content:
        if block.type == "tool_use":
            result = block.input

            # Validate the result
            if not result.get("order_id").startswith("ORD-"):
                # Send specific error back — not a generic "try again"
                messages.append({"role": "assistant", "content": response.content})
                messages.append({"role": "user", "content": [{
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": "order_id must start with ORD-. You returned: " + result["order_id"]
                }]})
                break  # go to next attempt

            return result  # valid — done

raise RuntimeError("Failed to get valid output after max retries")

Always send specific error details. Tell Claude which field failed and what you expected. A generic "try again" does not give Claude enough context to fix the issue.

Retry loops fix format errors. But if the data is simply not there in the source, retrying will not help. Claude cannot return something that does not exist.

Multi-pass Review

When Claude generates something and then reviews it in the same session, it already knows how it was built. It will miss its own mistakes. That is the problem with self-review.

Multi-pass review fixes this. You use a separate Claude session to review the output. The reviewer session has no memory of how the output was generated. It looks at the result with fresh eyes.

# Pass 1 — generate the code
generation_response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    messages=[{"role": "user", "content": "Write a FastAPI endpoint for processing refunds"}]
)
generated_code = generation_response.content[0].text

# Pass 2 — review in a separate session
review_response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": f"Review this code for security vulnerabilities:\n\n{generated_code}"}]
)

Never use the same session for generation and review. Always use a separate session.

Schema Design

When you define a JSON schema for structured output, each field tells Claude what to extract and in what format. One of those fields can be an enum. It is a fixed list of allowed values. For example, if you have an issue field you can restrict it to "missing", "damaged", or "wrong_item", you define it as an enum. Claude can only pick from that list.

Three things to know in Schema Design:

Enums - always add "other" to the list. If Claude sees something that does not fit any of the defined values, it will pick the closest one instead of telling you it does not know. With "other" in the list, Claude has a safe option to fall back to.

Nullable fields — if a field may not always be present, use ["string", "null"] instead of "string". Never mark optional fields as required. Claude will make up a value just to fill it.

Flat structures — avoid deeply nested objects in your schema. Deep nesting makes it harder for Claude to fill the schema accurately. Keep your schema flat. If the data is complex, split it across multiple tool calls.

tools = [{
    "name": "extract_order",
    "description": """Extract order details. Issue must be one of: missing, damaged, wrong_item, other.
    Use other when the issue does not fit the above categories.""",
    "strict": True,  # Claude must follow the schema exactly
    "input_schema": {
        "type": "object",
        "additionalProperties": False,  # no extra fields allowed
        "properties": {
            "customer_name": {"type": "string"},
            "order_id": {"type": "string"},
            # issue must be a string 
            # issue can only be one of these four values — always include "other" in enum.
            "issue": {
                "type": "string",
                "enum": ["missing", "damaged", "wrong_item", "other"]
            },
            # fill this when issue is "other" — gives Claude somewhere to put unexpected values
            "issue_detail": {"type": "string"},
            # nullable — Claude returns null when delivery date is not mentioned in the source
            "delivery_date": {"type": ["string", "null"]}
        },
        # only these fields are required — issue_detail and delivery_date are optional
        "required": ["customer_name", "order_id", "issue"]
    }
}]

2. Context Management & Reliability

This domain carries 15% of your exam score. It is the smallest domain. But it matters. If you do not manage context well, your agents become unreliable in production.

Below are the key concepts.

• Lost-in-the-Middle Effect

• Progressive Summarization

• Tool Result Trimming

• Escalation and Ambiguity

• Error Propagation

• Prompt Caching

• Message Batches API

Lost-in-the-Middle Effect

Claude can process up to 1 million tokens in a single request. But more context does not always mean better results.

When you pass a long input, Claude processes the beginning and end reliably. What is in the middle often gets missed. This is called the lost-in-the-middle effect.

Two things to know

• Place critical information at the beginning or end. Never place it in the middle.

• For large context tasks, delegate to subagents. Each subagent starts fresh with only what it needs.

Progressive Summarization

As an agent runs through multiple turns, the conversation history keeps growing. At some point it gets too large to pass in full on every API call.

Progressive summarization solves this. Instead of passing everything, you summarize the older turns and keep only the recent ones in full. The summary replaces the old turns in the messages array.

# When history gets too long, summarize older turns
summary_response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{
        "role": "user",
        "content": f"Summarize this conversation history into key facts only:\n\n{old_turns}"
    }]
)

summary = summary_response.content[0].text

# Replace old turns with the summary
messages = [
    {"role": "user", "content": f"Previous context: {summary}"},
    *recent_turns  # keep the last few turns in full
]

When we summarize, we may lose details. Dates, percentages, and numeric values often become vague. If you want anything to stay precise, extract it into a structured state object before summarizing.

Tool Result Trimming

Every tool call adds output to the context. If a tool returns 40 fields but you only need 5, the remaining 35 are wasting tokens. Over multiple turns this adds up fast and fills your context with noise.

Trim tool results before appending them to the next API messages array. Always keep your context clean. Pass only what Claude needs. Learn more about managing tool context here.

# Bad — full tool result, 40+ fields appended to messages
result = get_customer(customer_id="C-42")
messages.append({
    "role": "user",
    "content": [{
        "type": "tool_result",
        "tool_use_id": block.id,
        "content": json.dumps(result)
    }]
})

# Good — trim before appending, only what Claude needs
result = get_customer(customer_id="C-42")
trimmed = {
    "id": result["id"],
    "name": result["name"],
    "status": result["status"]
}
messages.append({
    "role": "user",
    "content": [{
        "type": "tool_result",
        "tool_use_id": block.id,
        "content": json.dumps(trimmed)
    }]
})

Escalation and Ambiguity

Not every task should be handled autonomously. Knowing when to escalate to a human is just as important as knowing how to complete a task.

Three valid reasons to escalate:

• When the user explicitly requests a human, escalate immediately. Do not attempt to investigate first.

• When the agent does not have clear instructions for the situation, escalate. Do not guess.

• When the agent cannot make meaningful progress, escalate.

When a tool returns multiple matching results, ask the user for more details to narrow it down. Never pick one based on a guess.

# Tool returns escalation signal
@mcp.tool()
def process_refund(order_id: str, amount: float) -> dict:
    if amount > 500:
        return {"requires_human": True, "reason": "Refund above $500 needs approval"}
    return {"success": True, "refund_id": "REF-001"}

# Agent loop checks for it
result = tool_map[block.name](**block.input)

if result.get("requires_human"):
    escalate_to_human(result)
    return

Two common mistakes to avoid.

Do not escalate just because the user seems frustrated. Frustration does not mean the task needs human intervention. Acknowledge it, try to resolve it, and only escalate if the user explicitly asks for a human.

Do not use the agent’s own confidence score as an escalation signal. Models tend to be overconfident even when they are wrong. It is not reliable.

Error Propagation

In a multi-agent system, when a subagent fails, the coordinator needs to know what went wrong. If the subagent returns a generic error, the coordinator cannot decide what to do next.

Subagents should always return structured error context. Not a generic failure status.

# Bad — coordinator has no idea what went wrong
return {"error": True}

# Good — coordinator knows what failed and what to do next
return {
    "error": True,
    "type": "tool_failure",
    "tool": "lookup_order",
    "reason": "Order not found in database",
    "retryable": False
}

Never suppress errors silently. If a subagent fails without sending a signal, the coordinator assumes success and moves on. That produces wrong results in the next steps.

Not all errors are the same. A timeout can be retried. A missing record cannot be retried. Tell the coordinator what went wrong so it can decide what to do.

Also remember, subagents do not share context automatically. If one fails, the coordinator has to pass that information forward explicitly.

Prompt Caching

Every time you call the Claude API, you send the full context. You send system prompt, conversation history, tool definitions. Claude processes all of it from scratch on every single call. That adds up fast. It becomes more tokens with higher cost.

With prompt caching we can reduce the cost. You mark the static parts of your prompt with cache_control. Claude caches them on the first call. Instead of paying full price on every call, you pay only 10% for the tokens that are already cached.

There are two ways to enable it.

Automatic caching - You just add cache_control at the top level of your request. Claude scans your prompt from top to bottom and places the cache breakpoint at the end of the last block that can be cached, which is typically the end of your system prompt or tool definitions.

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},  # automatic — Claude picks the breakpoint
    system="You are a customer support agent.................  ",
    messages=[{"role": "user", "content": user_query}]
)

Explicit caching - you mark specific content blocks with cache_control directly inside the system array. Claude caches everything before and up to that block. Use this when you want to control exactly where the cache ends.

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "You are a customer support agent."},
        {
            "type": "text",
            "text": large_document,
            "cache_control": {"type": "ephemeral"}  # cache everything up to here
        }
    ],
    messages=[{"role": "user", "content": user_query}]
)

Always cache static content only. You can put system prompts, tool definitions, and large documents in cache. Never put dynamic content in cache.

Every API call checks whether the cached prefix matches exactly. Even a single character difference causes a cache miss and Claude reprocesses everything from scratch.

TTL and pricing

TTL stands for Time to Live. It is how long the cache stays active. By default the cache expires after 5 minutes. Every cache hit resets the timer. If your requests come in less frequently, you can extend the TTL to 1 hour at 2x the cache write price.

• The first call writes to cache and costs 1.25x normal input tokens.

• Cache read costs 0.1x normal input tokens.

• You can place a maximum of 4 cache_control breakpoints in a single request.

• If you use the Batch API and prompt caching together, both discounts apply.

• The first call costs more because it writes to cache. From the 4th read onwards you start saving money.

To check if caching is working, look at the response usage.

print(response.usage.cache_read_input_tokens)     # tokens read from cache
print(response.usage.cache_creation_input_tokens)  # tokens written to cache

If cache_read_input_tokens is greater than 0, the cache was hit.

Message Batches API

When you need to process a large number of API requests without needing an immediate response, use the Message Batches API. For example, processing thousands of customer feedback forms overnight, or doing bulk content generation.

You can submit up to 100,000 requests in one batch. Claude processes them asynchronously. Most batches finish within 1 hour, but they can run up to 24 hours. If they do not complete within 24 hours, they expire.

The cost is 50% off standard API pricing. The output quality is the same. Only the timing is different.

import anthropic
import time

client = anthropic.Anthropic()

# Create a batch with multiple independent requests
batch = client.messages.batches.create(
    requests=[
        {
            # This custom id will be returned with the result, 
            # so we know this output is for feedback_001
            "custom_id": "feedback_001",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 500,
                "system": "You are a support analyst. Summarize customer feedback in 2 short bullet points.",
                "messages": [
                    {
                        "role": "user",
                        "content": "The app is useful, but the login takes too much time."
                    }]
            }},
        {
            # This custom id will be returned with the result
            # so we know this output is for feedback_002
            "custom_id": "feedback_002",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 500,
                "system": "You are a support analyst. Summarize customer feedback in 2 short bullet points.",
                "messages": [
                    {
                        "role": "user",
                        "content": "The dashboard is clean, but export to PDF is missing."
                    }]
            }}
    ])

print(f"Batch ID: {batch.id}")

# Wait until the batch completes
while True:
    current_batch = client.messages.batches.retrieve(batch.id)

    if current_batch.processing_status == "ended":
        break

    time.sleep(30)

# Read the results
for result in client.messages.batches.results(batch.id):
    if result.result.type == "succeeded":
        print(f"{result.custom_id}: {result.result.message.content[0].text}")

    elif result.result.type == "errored":
        print(f"Error in {result.custom_id}: {result.result.error}")

    elif result.result.type == "canceled":
        print(f"Canceled: {result.custom_id}")

    elif result.result.type == "expired":
        print(f"Expired: {result.custom_id}")

Three things to know.

• Use custom_id to tie each result back to your input. Without it you cannot match results to requests.

• You can combine the Batch API with prompt caching. Both discounts apply together, so if your requests share the same system prompt, use both for maximum savings.

• Use the Batch API for async workloads only. If you need a real-time response, use the standard Messages API.

3. How to Register for the exam

The exam is currently available to employees of companies in the Anthropic Partner Network. The Partner Network is free to join. Any company building with Claude qualifies for it.

Step 1 — Join the Partner Network

Your company needs to be part of the Anthropic Partner Network. If you are not in the partner network then apply for Claude Partner Network.

Step 2 — Request exam access

If you are already in the partner network, then login to the network and take up the exam.

Step 3 — About exam

60 questions. 120 minutes. No notes, no AI tools, no external resources are allowed.

Free prep resources

Free resources are available on Anthropic Academy and open to everyone. Start there regardless of whether you have exam access yet.

Certificate validity

The certificate is valid for 6 months. After that you need to recertify.

Conclusion

I hope this gave you a clear picture of what the exam covers. We went through all the domains across both parts.

I have also added 6 sets of practice questions to the GitHub repo.

These concepts are not just for the exam. Knowing them well will make you a better engineer when building with Claude.

Happy Learning!

I have been building agentic systems with Claude for a long time. When I heard about the exam, I wanted to understand what it actually tests.

So I went through the entire exam guide, also took some mock tests to understand what they covered.

Below are the sections you need to understand to become a Claude Certified Architect.

1. Agentic Architecture & Orchestration

2. Tool Design & MCP Integration

3. Claude Code Configuration

4. Prompt Engineering & Structured Output

5. Context & Reliability

Each section is detailed enough to be its own blog. We will cover the first three in this part. The remaining sections along with how to register will be in Part 2.

I have also put together a set of practice questions with answers on GitHub. I will keep adding more as I come across them.

1. Agentic Architecture & Orchestration

This section carries 27% of your exam score. It covers Claude Agent SDK, the library you use to build production grade agents. Below are the key Agent SDK concepts, that turn a normal LLM into an agent.

• stop_reason

• Conversation History

• Loop Termination

• Multi-Agent Systems

• Task Decomposition

• Hooks

• Session Management

A normal LLM call is simple. You send a message, Claude replies, done. An agent is different. It is multiple LLM calls chained together until the task is fully complete. It includes tool calling, getting results, and deciding what to do next.

Let us start with stop_reason. It is the core of every agent loop.

stop_reason

Every Claude API response has a field called stop_reason. It tells you why Claude stopped. This is what decides whether your loop continues or ends. stop_reason has multiple values. The three you need to know for the exam are,

If stop_reason == "tool_use" then it means Claude wants to call a tool. Then you execute the tool, append the result, and loop again.

If stop_reason == "end_turn" then Claude is done. We can return the response to the user. Loop ends.

If stop_reason == "max_tokens" then the response got cut off. This happens when Claude hits the max_tokens limit you set in the API call.

If the response genuinely needs more tokens, increase max_tokens. If the response is too verbose, then restructure your prompt to produce a shorter output. Never return a cut-off response as it is incomplete.

Here is the stop_reason with all three options, explained in code.

import anthropic
import json

client = anthropic.Anthropic()

class Agent:
    def __init__(self, tools):
        self.tools = tools

    def run(self, task: str) -> str:
        # Every conversation starts with the user task
        messages = [{"role": "user", "content": task}]

        while True:
            # Claude does not remember previous call, 
            # So we pass the full conversation history every time
            response = client.messages.create(
                model="claude-sonnet-4-6",
                max_tokens=1024,
                tools=self.tools,
                messages=messages
            )

            # Check the stop_reason to ensure the Task is complete
            if response.stop_reason == "end_turn":
                return extract_text(response.content)
            
            # If stop_reason is tool_use then execute the tool
            elif response.stop_reason == "tool_use":

                # Step 1 — save what Claude said, including which tool it wants to call
                messages.append({
                    "role": "assistant",
                    "content": response.content
                })

                for block in response.content:
                    if block.type == "tool_use":

                        # Step 2 — we execute the tool, not Claude
                        result = tool_map[block.name](**block.input)

                        # Step 3 — send the tool result back so Claude can continue
                        # tool_use_id tells Claude which tool call this result belongs to
                        messages.append({
                            "role": "user",
                            "content": [{
                                "type": "tool_result",
                                "tool_use_id": block.id,
                                "content": json.dumps(result)
                            }]
                        })
                # Claude now sees the result and decides what to do next

            else:
                # stop_reason == "max_tokens" — response was cut off, never return incomplete results
                raise RuntimeError(f"Unexpected: {response.stop_reason}")

The loop runs until Claude returns end_turn.

Handling stop_reason is one of the most important concepts in agentic workflows. Learn more in the official docs.

Now that you understand stop_reason, let us look at how Claude keeps track of everything that happens in the loop.

Conversation History

In agentic workflows, Claude has no memory between API calls. Every time you call the API, you have to pass the full conversation history. That is how Claude knows what happened before.

The messages array holds that history. User messages, Claude responses, and tool results all get appended here until the task is done.

So how does the messages array grow? Every time stop_reason == "tool_use", you append two things.

First, you append the response Claude just sent. This contains the tool name Claude wants to call and the input values it decided to pass.

messages.append({
    "role": "assistant",
    "content": response.content    # text block + tool_use block
})

Then you execute the tool and append the result back. The tool_use_id in the result must match the one from the response we appended previously. This tells Claude that this result is for the tool call it requested.

Now you loop again. Claude reads everything in the messages array and decides what to do next.

for block in response.content:
    if block.type == "tool_use":
        result = tool_map[block.name](**block.input)

        messages.append({
            "role": "user",
            "content": [{
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": json.dumps(result)
            }]
        })

Do not add text immediately after tool results. Send tool results directly without additional text

Loop Termination

An agent loop can terminate for different reasons. We need to identify each termination reason and handle it. If we do not, the agent either runs forever, returns incomplete results, or takes actions it should not.

Here are the three ways we handle it.

• stop_reason == "end_turn" - Claude is done. Return the response to the user and exit the loop.

• result.get("requires_human") == True - escalate to a human and exit the loop.

• MAX_ITERATIONS = 10 - the loop hit the safety cap. Raise an error and exit.

In all three cases, we handle the termination and never return incomplete results. Here is how all three work together in code.

MAX_ITERATIONS = 10

def escalate_to_human(result: dict) -> None:
    # Notify your human review system — ticket, Slack, email etc.
    print(f"Escalating to human: {result}")

def extract_text(content) -> str:
    # Extract the text block from Claude's response
    for block in content:
        if hasattr(block, "text"):
            return block.text

class Agent:
    def __init__(self, tools):
        self.tools = tools

    def run(self, task: str) -> str:
        # Every conversation starts with the user task
        messages = [{"role": "user", "content": task}]

        for i in range(MAX_ITERATIONS):
            # Claude does not remember previous calls
            # So we pass the full conversation history every time
            response = client.messages.create(
                model="claude-sonnet-4-6",
                max_tokens=1024,
                tools=self.tools,
                messages=messages
            )

            # Claude is done — return the response to the user
            if response.stop_reason == "end_turn":
                return extract_text(response.content)

            elif response.stop_reason == "tool_use":
                # Append Claude's response to history
                messages.append({
                    "role": "assistant",
                    "content": response.content
                })

                for block in response.content:
                    if block.type == "tool_use":
                        # we execute the tool
                        result = tool_map[block.name](**block.input)

                        # Tool requires human intervention — escalate and exit the loop
                        if result.get("requires_human"):
                            escalate_to_human(result)
                            return

                        # Append tool result so Claude can continue
                        messages.append({
                            "role": "user",
                            "content": [{
                                "type": "tool_result",
                                "tool_use_id": block.id,
                                "content": json.dumps(result)
                            }]
                        })

        # Max iterations reached — exit with error, never return incomplete results
        raise RuntimeError("Agent hit max iterations without completing")

Multi-Agent Systems

You now know how a single agent works. But some tasks are too complex for one agent to handle alone.

That is where multi-agent systems come in. You break the work across multiple specialized agents. Each one is the same Agent class we defined in the previous sections, just with different tools and a different responsibility.

search_agent = Agent(tools=[web_search_tool])
analysis_agent = Agent(tools=[analysis_tool])
report_agent = Agent(tools=[report_tool])

Anthropic uses a pattern called hub-and-spoke to coordinate agents. Think of it like this. One coordinator receives the task, breaks it down, and delegates to specialized agents. Each agent does its part and reports back. The coordinator collects everything and produces the final response.

Now, when do you run agents in parallel and when in sequence?

If the tasks are independent, run them in parallel. If one task needs the output of another, run them in sequence.

import asyncio

# Step 1 — Independent subagents, run in parallel
search_result, document_result = await asyncio.gather(
    search_agent.run("Search web for competitors"),
    analysis_agent.run("Analyze our internal documents")
)

# Step 2 — This subagent depends on Step 1, runs after
report_result = report_agent.run("Generate report", search_result, document_result)

# Step 3 — Coordinator collects all results and produces the final response
final_result = coordinator_agent.run("Finalize", search_result, document_result, report_result)

Every subagent starts with a fresh context. It does not have access to the coordinator's conversation history. The only way to pass context to a subagent is through its prompt. So be specific and detailed in what you pass.

# Too vague — subagent does not know enough to do its job well
search_agent.run("Search web for competitors.")

# Right — give the subagent exactly what it needs
search_agent.run("Search web for competitors in the B2B SaaS space. Focus on pricing and features.")

Agents never talk directly to the user. They always report back to the coordinator. The coordinator owns the task from start to finish.

Task Decomposition

Task decomposition is an important part of building multi-agent systems. When you build one, remember that your coordinator agent should never delegate a vague task directly to a subagent.

Take this for example. Your coordinator receives “Research the competitive landscape for our project management tool.” If it passes this directly to a subagent, the subagent does not know where to start. You will get different results every run.

Break it down first.

• Search Google for “Notion vs Linear pricing plans 2026”

• Extract pricing tiers, feature limits, and target user segments for both

• Generate a comparison table showing where your product has an advantage

Each subtask goes to one specialized agent. Each agent has one job and knows exactly what to return.

The agents are not the problem. Vague instructions are.

Hooks

When you build an agent, some actions need to be controlled programmatically. You cannot rely on Claude to always follow prompt instructions. That is where hooks come in.

Hooks are callback functions you register in the Claude Agent SDK. They fire automatically at specific points during agent execution. No prompts involved.

Two hooks you need to know for the exam,

PreToolUse :

It fires before a tool executes. Since it runs before, it can block the action. Use it when you want to stop Claude from doing something like blocking rm -rf commands, preventing writes to .env, or requiring human approval before processing a refund above $500.

PostToolUse :

PostToolUse fires after a tool executes. It cannot block anything since the action already happened. Use it for things like auto-formatting a file after Claude edits it, writing to an audit log after a deletion, or running a linter after every code change.

Here is a real example. Your agent has a process_refund tool. Any refund above $500 needs human approval before it goes through.

from claude_agent_sdk import ClaudeAgentOptions, ClaudeSDKClient, HookMatcher

async def block_large_refunds(input_data, tool_use_id, context):
    tool_name = input_data["tool_name"]
    tool_input = input_data["tool_input"]

    # Only intercept the process_refund tool
    if tool_name != "process_refund":
        return {}  # allow all other tools to proceed

    # Block refunds above $500 — requires human approval
    if tool_input.get("amount", 0) > 500:
        return {
            "hookSpecificOutput": {
                "hookEventName": input_data["hook_event_name"],
                # deny stops the tool from executing
                "permissionDecision": "deny",
                # this reason is sent back to Claude so it knows why it was blocked
                "permissionDecisionReason": "Refunds above $500 require human approval"
            }
        }

    # Allow refunds under $500 to proceed normally
    return {}

options = ClaudeAgentOptions(
    hooks={
        # PreToolUse fires before the tool executes
        "PreToolUse": [
            # matcher tells the SDK which tool to intercept
            HookMatcher(matcher="process_refund", hooks=[block_large_refunds])
        ]
    }
)

async with ClaudeSDKClient(options=options) as client:
    await client.query("Process a $600 refund for order ORD-999")
    async for message in client.receive_response():
        print(message)

The key difference between hooks and prompt instructions is reliability. A prompt instruction like “never process refunds above $500” is not guaranteed. Claude may follow it or not. A hook always fires. If you want something enforced without exception, put it in a hook.

Session Management

A session contains the full conversation history. The SDK saves it to disk automatically so you can come back to it later.

Here is what you need to know.

• Session Resumption

• Session Isolation

• Session Forking

Session Resumption

Imagine your agent is halfway through a long task and the server crashes. Without session resumption, it starts from scratch. With it, you pass the session ID and the agent continues from where it stopped.

Here is how you implement it.

from claude_agent_sdk import ClaudeAgentOptions, query, ResultMessage

# Start a session and save the session ID
session_id = None
async for message in query("Analyze the refund flow in our codebase"):
    if isinstance(message, ResultMessage):
        session_id = message.session_id

# Resume later — agent has full context from before
async for message in query(
    prompt="Now fix the bug you found",
    options=ClaudeAgentOptions(
        resume=session_id,
        allowed_tools=["Read", "Edit", "Write", "Glob", "Grep"],
    ),
):
    if isinstance(message, ResultMessage) and message.subtype == "success":
        print(message.result)

Session Isolation

Each user or task gets its own session. If two users share the same session, Claude will mix up their context and produce wrong results. Always create a new session for each user or task.

Session Forking

Sometimes you want to try a different approach from where you are, without affecting your current session. For example, your agent has analyzed a codebase and you want to try both a REST and a GraphQL implementation. Instead of starting over, you fork the session. Both forks start from the same point. The original stays untouched.

from claude_agent_sdk import ClaudeAgentOptions, query

# Fork — original session stays unchanged
options = ClaudeAgentOptions(
    resume=session_id,
    fork_session=True   # new session ID, same history
)

async for message in query("Try a GraphQL approach instead", options=options):
    print(message)

To learn more about working with sessions, check out the Claude Agent SDK session guide.

2. Tool Design & MCP Integration

MCP stands for Model Context Protocol. It is an open standard for connecting your agent to external services. For example, your agent can query a database, fetch GitHub issues, or send a Slack message through an MCP server.

If you are new to MCP, check out our complete MCP Server Guide that covers everything from scratch.

Below are the key concepts.

• MCP Components

• Tool Descriptions

• Structured Error Responses

• Tool Distribution

• MCP Server Configuration

MCP Components

An MCP server consists of three things.

• Tools are functions exposed by the MCP server. When Claude calls a tool, the MCP server executes that function. Claude decides when to call the tool and what input to send.

• Resources are read only data exposed by the MCP server. They give Claude extra context for the task. For example, a resource can be an API spec, database schema, product catalog, or project document.

• Prompts are reusable instructions exposed by the MCP server. They tell Claude how to handle a repeated task. In supported clients, prompts can also be triggered as slash commands.

Here is a simple MCP server example. This one connects to PostgreSQL and shows all three components.

from mcp.server.fastmcp import FastMCP
import psycopg2
import os

mcp = FastMCP("DatabaseServer")

# Connect to PostgreSQL — use environment variables for credentials
conn = psycopg2.connect(
    host=os.getenv("DB_HOST"),
    database=os.getenv("DB_NAME"),
    user=os.getenv("DB_USER"),
    password=os.getenv("DB_PASSWORD")
)

# Tool — model calls this to query the database
@mcp.tool()
def get_order(order_id: str) -> dict:
    """Look up an order by order ID from the database."""
    cursor = conn.cursor()
    cursor.execute("SELECT id, status, item FROM orders WHERE id = %s", (order_id,))
    row = cursor.fetchone()
    
    if not row:
        return {"error": "Order not found"}
    
    return {"id": row[0], "status": row[1], "item": row[2]}

# Resource — exposes the full product catalog from the database
@mcp.resource("data://product-catalog")
def get_product_catalog() -> str:
    """Returns all products from the database."""
    cursor = conn.cursor()
    cursor.execute("SELECT name, price FROM products")
    rows = cursor.fetchall()
    return "\n".join([f"{row[0]} - ${row[1]}" for row in rows])

# Prompt — can appear as a slash command in supported clients
@mcp.prompt()
def review_order_prompt() -> str:
    """Template for reviewing an order status."""
    return """You are an order review specialist. 
When reviewing an order:
- Check the current status
- Identify any issues
- Suggest next steps"""

if __name__ == "__main__":
    mcp.run()

Once this MCP server is running and connected to your agent, you can query it directly.

“What is the status of order ORD-999?”

The agent calls the get_order tool, queries the database in real time, and returns the result.

Tool Descriptions

When Claude has multiple tools, it uses the tool description to decide which one to call. If the description is vague, Claude may pick the wrong tool.

A good tool description should clearly say three things.

• What the tool does

• What input it expects

• When to use it and when not to

# Bad — too vague, Claude cannot differentiate
@mcp.tool()
def get_order(order_id: str) -> dict:
    """Retrieves order details."""
    ...

# Good — clear boundaries, Claude knows exactly when to use it
@mcp.tool()
def get_order(order_id: str) -> dict:
    """Look up an order by order ID. 
    Use this when you need order status, items, and shipping details. 
    Do not use this for customer account lookups."""
    ...

Structured Error Responses

When a tool fails, do not return a generic error. Claude needs to know what went wrong so it can decide what to do next.

In production, return more than just an error. Tell Claude what went wrong, whether it can retry, and what to do next.

Here are a few common categories.

• Transient - If the external service is down or timed out, we return the error as transient. It means the failure is temporary and usually safe to retry.

• Validation - If the input is missing or invalid, we return the error as validation. It means Claude should fix the input before calling the tool again.

• Business - If the tool runs, but the action is not allowed by your system rules, we return the error as business. It means there is no point retrying the same request.

• Permission - If the user or agent does not have access to perform the action, we return the error as permission. It means access should be granted first before retrying.

@mcp.tool()
def process_refund(order_id: str, amount: float) -> dict:
    """Process a refund for a given order."""

    # validation — bad input, no point retrying
    if not order_id:
        return {"error": True, "errorCategory": "validation", "isRetryable": False, "message": "order_id is required"}

    # business — order is not eligible for refund, refund window has expired
    if order_status == "delivered_over_30_days":
        return {"error": True, "errorCategory": "business", "isRetryable": False, "message": "Refund window has expired. Orders can only be refunded within 30 days of delivery."}
    
    # transient — service down, safe to retry
    if not payment_service.is_available():
        return {"error": True, "errorCategory": "transient", "isRetryable": True, "message": "Payment service unavailable. Try again."}

    return {"success": True, "refundId": "REF-001"}

Never return a generic error like {"error": "Operation failed"}. The more context you give Claude, the better it recovers.

Tool Distribution

Give each agent only the tools it really needs. Too many tools can confuse Claude. It may call the wrong tool or take the wrong action.

# Bad — agent has access to tools it should never use
research_agent = Agent(tools=[
    web_search_tool,
    process_refund_tool,    # research agent should never process refunds
    delete_record_tool,     # research agent should never delete records
    synthesis_tool
])

# Good — agent only gets what it needs
research_agent = Agent(tools=[
    web_search_tool,
    synthesis_tool
])

Use allowed_tools and disallowed_tools in the Claude Agent SDK to control which tools each agent can access.

options = ClaudeAgentOptions(
    mcp_servers={"orders": order_server},
    allowed_tools=[
        "mcp__orders__get_order",       # pre-approve read operations
        "mcp__orders__get_customer"
    ],
    disallowed_tools=[
        "mcp__orders__delete_record",   # block delete operations
        "mcp__orders__update_record"    # block write operations
    ]
)

To learn more, check the official SDK reference.

MCP Server Configuration

When you add an MCP server to your project, you need to decide where to configure it. There are two scopes.

• Project level — .mcp.json in your repo. It can be shared with the whole team via version control.

• User level — ~/.claude.json. It is personal and experimental. It is not shared.

// .mcp.json — project level, committed to the repo
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@anthropic-ai/mcp-server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"  // never hardcode secrets
      }
    },
    "database": {
      "command": "python",
      "args": ["./mcp_servers/database_server.py"],
      "env": {
        "DB_URL": "${DATABASE_URL}"
      }
    }
  }
}

Use existing community MCP servers for standard integrations like GitHub, Slack, and Jira. Build custom servers only for internal or team-specific workflows.

Check the official docs for MCP and Agent SDK integration.

3. Claude Code Configuration & Workflows

Claude Code deserves its own blog. We have covered the important concepts that will be useful for your daily development as well as for the exam.

• CLAUDE.md

• Custom Commands and Skills

• Path-specific Rules

• Plan Mode vs Direct Execution

• Headless Mode

• Hooks

• Built-in Tools

CLAUDE.md

CLAUDE.md is the first file Claude reads when it starts a session. It tells Claude the project conventions and rules.

It supports three levels:

• User level — ~/.claude/CLAUDE.md. Applies to all your projects.

• Project level — CLAUDE.md in the repo root. Applies to the whole project. Commit this to Git.

• Directory level — CLAUDE.md inside a subdirectory. Applies only when Claude is working in that folder.

repo/
├── CLAUDE.md              # applies to everything
├── frontend/
│   └── CLAUDE.md          # applies only in /frontend
└── backend/
    └── CLAUDE.md          # applies only in /backend

It can be placed directly in the repo root or inside the .claude/ directory. Both work the same way.

CLAUDE.md is advisory. Claude reads it and tries to follow it. But it is not guaranteed. Claude may not always follow it. If you have a constraint that must always run without exception, put it in a hook. Hooks fire programmatically and always run regardless of what Claude decides.

Custom Commands and Skills

Skills give domain-specific expertise to Claude. You package your team’s workflows, standards, and best practices into a SKILL.md file. Claude picks them up automatically when the task matches, or you call them directly with a slash command.

Skills live in two places:

• .claude/skills/ — project level. Shared with the team via Git.

• ~/.claude/skills/ — user level. Personal, not shared.

Each skill lives in its own subdirectory. For example, a review-security skill would be at .claude/skills/review-security/SKILL.md.

<!-- .claude/skills/review-security/SKILL.md -->
---
name: review-security
description: Run a security audit on the current file
allowed-tools: Read, Grep
context: fork
argument-hint: [file-path to review]
---

Review this file for SQL injection, XSS, and hardcoded secrets.
Output findings as JSON with severity, line number, and recommendation.

Three fields to know:

• allowed-tools - It controls which tools the skill can use. For example, if you set Read, Grep, the skill can only read files and search. It cannot write or run commands.

• context: fork - It runs the skill in a separate session. Whatever Claude does in that session stays there. Use this when you want Claude to explore something without affecting your main session.

• argument-hint - It shows a hint when someone types the slash command. It helps the user to understand what input to provide.

All fields are optional. But always include description so Claude knows when to load the skill automatically. Check the full frontmatter reference for all available fields.

Custom Commands were the older way to define slash commands in Claude Code. They lived in .claude/commands/*.md. Skills have now replaced them. If you are starting fresh, use Skills.

You can also find community-built skills at skills.sh.

Path-specific Rules

Rules live in .claude/rules/ as markdown files. When you want path-specific rules for your codebase, you add a paths field in your rules.

<!-- .claude/rules/frontend-rules.md -->
---
paths:
  - "frontend/**/*.ts"
  - "frontend/**/*.tsx"
---

Always use React functional components.
Never use class components.
Use Tailwind for styling. Never use inline styles.

<!-- .claude/rules/backend-rules.md -->
---
paths:
  - "backend/**/*.py"
---

Always use FastAPI for routes.
Business logic goes in services/. Never in routes/.
Always add type hints.

When you write rules like above, Claude picks up the right rules based on the file it is touching. This is more token efficient than putting all rules in one big CLAUDE.md.

Note: The official docs use paths: but some versions of Claude Code work more reliably with globs:. If paths: does not work, try globs: with your pattern instead.

Plan Mode vs Direct Execution

By default, Claude executes tasks immediately. It reads files, writes code, runs commands without stopping.

Plan mode changes that. Claude outlines what it is going to do first. No files written, no commands run. You review the plan and approve before anything happens.

claude --permission-mode plan

Use plan mode for large scale or destructive changes. For small, well-scoped tasks, just run directly.

Headless Mode

Headless mode runs Claude non-interactively using the -p flag. No terminal prompts. No approvals. Used for CI/CD pipelines and automation scripts.

claude -p "Review this PR for security vulnerabilities" --output-format json > report.json

Use --output-format json when you need the output in json.

Check more about Claude’s mode in the Claude Code docs.

Hooks

We already covered hooks in the Claude Agent SDK section. The concept is the same but the implementation is different in Claude Code.

In the Agent SDK, hooks are Python callback functions. In Claude Code, hooks are shell commands configured in .claude/settings.json. They fire automatically at specific points in Claude Code’s lifecycle.

As we already saw, two hooks matter here.

PreToolUse fires before a tool executes and can block the action. PostToolUse fires after tool execution. Here is how they look in Claude Code.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{"type": "command", "command": "echo '$CLAUDE_TOOL_INPUT' | grep -q 'rm -rf' && exit 2 || exit 0"}]
    }],
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{"type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"}]
    }]
  }
}

Built-in Tools

Claude Code ships with built-in tools. As an architect, you need to know when each one is the right choice.

Tool              When to use
-------           -----------
Read              Read the contents of a file
Write             Create or overwrite a file
Edit              Make targeted changes to a specific file
Bash              Run shell commands
Grep              Search for patterns inside file contents
Glob              Find files by name or pattern
LSP               Code intelligence — jump to definitions, find references, get type errors
Agent             Spawn a subagent with its own context window to handle a task
WebFetch          Fetch content from a URL
WebSearch         Search the web
Skill             Run a skill within the main conversation
NotebookEdit      Edit Jupyter notebook cells
AskUserQuestion   Ask the user a multiple choice question to clarify requirements

These are the most commonly used tools. Claude Code has many more built-in tools. Check the full tools reference for the complete list.

Up Next:

That is it for Part 1.

We covered agentic architecture, MCP integration, and Claude Code configuration.

In Part 2, we will move to the remaining areas. That includes prompt engineering, structured outputs, context management, reliability, and the registration flow.

I have added the mock test materials to this GitHub page. I will keep adding more questions as I find useful ones.

If you are planning to take the exam, use this blog and the mock questions as a practical guide. But before the exam, make sure you also go through the official docs once.

See you in Part 2.

What I liked first was the variety of channels OpenClaw supports. I can use it from Slack, WhatsApp, and Telegram. I just message it there, and it runs the task for me.

But that power is also where the risk starts. So, it is better to run OpenClaw in an isolated environment where it does not have direct access to your main machine.

I spent time using it on real day to day tasks and picked a few practical workflows that are worth sharing. I will start with the basics, then move into the workflows.

Here is what we will cover.

1. What is OpenClaw

2. Installation and Setup for Local, Docker, and Cloud

3. OpenClaw Workflow and Automation

   1. How I fix GitHub issues from slack

   2. How I use cron to check pull requests and spot the ones ready to merge

   3. How I setup daily AI updates through WhatsApp

4. Adding Custom Skills to OpenClaw

5. OpenClaw Agent in Moltbook

1. What is OpenClaw

OpenClaw is an open-source personal AI assistant that runs on your own machine. You can talk to the AI assistant from chat apps such as WhatsApp, Telegram, Slack, Discord, and Teams.

The diagram below shows how it works internally. What impressed me most is how clearly OpenClaw separates the agent from the rest of the system. The gateway, configuration, and lifecycle components are well organized. So, it becomes much easier to understand and debug when something goes wrong.

Gateway

Messages come in from channels like WhatsApp, Slack, or web chat. The gateway receives them and sends them to the right agent. It also keeps the session active and queues follow ups if a run is already happening.

Agent

The agent is the brain. OpenClaw builds the prompt and context, then passes your message to the agent. The agent decides the next step, uses tools if needed, and replies back.

Tools and Skills

Tools do the actual work. They can run shell commands, browse, call APIs, read files, or send messages. Skills are reusable workflows that tell the agent how to use those tools for a task.

Memory

Memory helps the agent remember. It stores project notes and past context so you do not have to repeat the same details every time.

This diagram shows how messages flow through OpenClaw from user input to agent reasoning and action.

2. Installation and Setup

Local Installation

Local setup is straightforward. Run this one-line command.

curl -fsSL https://openclaw.ai/install.sh | bash

You will then go through a short onboarding flow where you choose options based on your setup. It’s a simple process, and you can always configure channels and skills later.

Docker Installation

If you are not comfortable running OpenClaw directly on your system, Docker is a great option. It keeps the environment more isolated and safer.

git clone https://github.com/openclaw/openclaw
cd openclaw
./docker-setup.sh

This time, I used manual onboarding so I could follow each step clearly.

Once installed, you will typically see two key locations.

• ~/.openclaw - stores config, memory, and keys

• ~/openclaw/workspace - the agent workspace

If your dashboard is not connecting, then try this.

docker compose run --rm openclaw-cli dashboard --no-open

Other hosting methods

OpenClaw already provides clear guides for hosting on Render, Railway.

• OpenClaw deployment on Render

• OpenClaw deployment on Railway

• You can also run OpenClaw on Cloudflare using moltworker.

3. OpenClaw Workflow and Automation

One part I really wanted to test was how OpenClaw fits into day-to-day workflow, especially for development tasks.

Slack Integration

For my testing, I connected Slack and WhatsApp. Before connecting Slack to OpenClaw, I first created a Slack app. OpenClaw already has clear documentation for Slack app setup.

Here are the exact steps I followed.

Create the Slack app + enable Socket Mode

1. Go to https://api.slack.com/apps

2. Click Create New App → From scratch → Give App Name → Select Workspace

3. Open Socket Mode and turn it ON → In Basic Information → App-Level Tokens, generate a token with scope connections:write

4. Copy this App Token (xapp-...)

5. Go to OAuth & Permissions

6. Add bot scopes (minimum needed):
   chat:write, app_mentions:read, channels:history, groups:history, im:history, im:read, im:write, mpim:history, reactions:read, reactions:write, pins:read, pins:write, commands

7. Go to Install App → Click Install to Workspace

8. Copy the Bot User OAuth Token (xoxb-...)

Once the Slack App is created, use openclaw configure to connect the slack app.

How I fix GitHub issues directly from slack

Once Slack is connected, I can talk to OpenClaw directly from Slack and use it to handle GitHub issues.

When a new issue comes in, I ask OpenClaw to take a look. It reads the issue, checks my local code, makes the fix, and pushes the change back to GitHub. It also posts a reply on the issue with a short note on what it fixed.

In short: I can go from issue → fix → update, without constantly switching tools.

How I use cron to check pull requests and see which ones are ready to merge

As a GitHub repository maintainer, I like checking which pull requests are merge-ready first thing in the morning. So I set up a daily cron job in OpenClaw.

Every morning, it checks recent PRs and verifies whether the basic merge conditions are met, such as.

• no merge conflicts

• required CI/status checks passed

• required approvals completed

This gives me a quick “merge-ready vs not-ready” snapshot without manual checking. Setting up cron in OpenClaw is simple. You can either.

• use the CLI (openclaw cron add), or

• ask the agent in chat to create it for you.

Here is how i get my daily PR Report.

How I set up my AI Daily Digest with OpenClaw + WhatsApp

I wanted a daily AI news summary delivered to my personal WhatsApp, using newsletters that already land in my Gmail label called “AI digest.”

What I wanted

• Source: Gmail label - AI digest

• Output: Concise AI summary to my WhatsApp

• Schedule: 10:00 AM IST daily

• Query support: “what’s the last week updates?”

At first, I considered Gmail push automation (webhook/Pub/Sub) using the official docs. But that route needed extra infrastructure (like Tailscale). I tried it, but Tailscale was blocked on macOS in my setup, so I dropped that approach and moved to a simpler CLI + cron flow.

Whatsapp Integration

Setup: gog CLI + OpenClaw cron

Here’s the exact setup I used.

1. Install - gog CLI (Google Workspace CLI) on the host.

2. Configure Google OAuth client credentials for gog.

3. Enable Gmail API in Google Cloud Console.

4. Get/download Google OAuth client JSON.

5. Register credentials with gog

   gog auth credentials set /path/to/client_secret.json

6. Authenticate Gmail account for CLI access

   gog auth add "your-email"  --services gmail

7. Test auth

   gog auth list

8. Test search query (last 24h email from AI Digest)

   gog gmail messages search "label:\"AI digest\" newer_than:1d" --account "your-email-id" --max 50 --json

9. Set up cron job in OpenClaw

   openclaw cron add \
     --name "Daily AI digest from Gmail label" \
     --session isolated \
     --cron "0 10 * * *" \
     --tz "Asia/Kolkata" \
     --message 'Using gog with account "your-email-id", check Gmail label "AI digest" for emails from the last 24 hours. Extract the most important AI updates/news, deduplicate repeated stories, and send a concise WhatsApp digest with: (1) top updates as bullets, (2) why each matters in one line, and (3) links/sources when available. If no relevant emails are found, say there were no major AI updates in the last 24 hours.' \
     --announce \
     --channel whatsapp \
     --to "your-whatsapp-number" \
     --timeout 180000 \
     --timeout-seconds 120 \                                                                  

10. Once this is active, OpenClaw automatically delivers the AI digest to WhatsApp through its messaging route.

    

Notes/Troubleshooting

1. If cron fails with "missing refresh token" then do re-auth again.

gog auth add "your-email-id" --services gmail

2. Always configure both gateway and agent timeouts for cron jobs.

Openclaw commands

These are the commands I used while working with OpenClaw

• openclaw configure — Runs interactive setup after installation.

• openclaw dashboard --no-open — Opens the OpenClaw UI in browser.

• openclaw devices list — Shows paired devices and their status.

• openclaw plugins list — Lists installed/available plugins and their state.

• openclaw security audit — Runs a standard security audit.

• openclaw security audit --deep — Runs deep security audit.

• openclaw status — Quick overall health check of gateway, channels etc..

• openclaw doctor — Diagnoses common setup/runtime issues and suggests fixes.

• openclaw gateway status — Checks whether the gateway service is running.

• openclaw gateway restart — Restarts the gateway service (very useful after config/auth changes).

• openclaw logs — Shows gateway logs for debugging.

• openclaw cron list — Lists all scheduled cron jobs.

• openclaw cron runs —-id <job-id> — Shows execution history for a specific cron job.

• openclaw cron run <job-id> — Manually triggers a cron job for testing.

• openclaw cron rm <job-id> — Deletes a cron job.

• openclaw message send ... — Sends a test/proactive message (useful for validating delivery routes).

For more commands: https://docs.openclaw.ai/cli

4. Adding Custom Skills

You can add custom skills to openclaw. Check skills.sh. Select the skill you want to add. Get inside the workspace and install the skill.

5. OpenClaw Agent in Moltbook

If you are interested about giving your agent a more “social” layer, Moltbook is an interesting add-on to explore.

Moltbook - Social network for AI Agent

Read this, before you try OpenClaw

OpenClaw is powerful. That is also why you should be careful.

Safety tips

• Do not run this on your primary machine.

• Use Docker or a VM or a spare laptop.

• Give only the permissions you need.

• Treat it as an experiment, not production.

• Stick to official sources for downloads and updates.

Conclusion

Now you have seen what OpenClaw is and a few workflows and automations. For daily work, it can save time and reduce tool switching.

I am still exploring more workflows and use cases. If you are experimenting with OpenClaw, start with one simple workflow and build from there.

Hope this post helps you get started.

Happy building!

Claude Skills are the newest addition to this workflow. Skills teach domain expertise.

Anthropic released Claude Skills in October 2025. They added document creation & handling capabilities to Claude using Skills. They also open-sourced the production Skills that power Claude's capabilities.

Skills unlock full potential when combined with other tools. You can combine skills with hooks and MCP Servers to automate your workflows. Since Skills launched, developers use Claude as a general-purpose agent for more than just coding.

So, I’m covering about Claude Skills and how I use them in my workflow.

1. What are Claude Skills

2. Why Claude Skills

3. Skills Vs MCP

4. Automate - Git Commit, PR workflow with Claude Skills

5. Automate - Invoice Generation with Claude Skills

6. Top Claude Code skills

1. What are Claude Skills

Skills are folders with a SKILL.md file containing instructions. The folder can also include scripts, templates, and reference docs. Each skill is self-contained in its own folder. Skills teach Claude how to complete specific tasks. They are reusable too. Claude loads the right skill when its needed.

SKILL.md starts with YAML metadata and then the instructions. The metadata includes fields like name and description. Claude uses the description to decide when to apply the Skill.

A skill is not just a markdown file. It can include code samples, reference docs, and templates in the same folder.

In Claude Code, you can keep Skills in two places.

• Personal Skills go in ~/.claude/skills/. It can work across projects.

• Project Skills go in .claude/skills/. You can commit them and share them with your team.

A big advantage of Skills is they are not loaded fully all the time. Claude reads small metadata first to identify the right skill. Then it loads full instructions only when needed. This keeps your context clean. You can use heavy skills with scripts and docs without bloating tokens.

Skills also work across Claude app, Claude Code. You can also integrate skills to your agent.

2. Why Claude Skills

Here is why Claude Skills are worth adding to your workflow.

3. Skills Vs MCP

Here is a quick side by side view of how Claude Skills and MCP differ.

4. Automate - Git Commit, PR workflow with Claude Skills

Git commits and PR creation happen daily in my work. Running type checks, linting, writing commit messages, and filling PR descriptions add up over time.

I built a skill to automate this workflow. The skill manages everything from pre-commit checks to PR creation. It runs quality checks before every commit, commits the code with proper messages, and automatically raises pull requests with descriptions.

Claude Code handles commits and PRs natively with Git CLI. But it won't follow your exact patterns. I needed standardized commit messages, specific PR templates, and quality checks in my preferred order. So, I built a skill that enforces my workflow.

The Setup

I have three components in my workflow.

CLAUDE Skill - Workflow Orchestrator

It defines the commit-to-PR workflow. It summarizes changes, proposes commit messages, runs pre-commit checks, and orchestrates PR creation with proper descriptions.

Hook for Pre-commit Checks

It intercepts git commit commands. It runs lint, type check, and tests automatically. When checks fail, it blocks the commit and returns errors.

GitHub MCP Server - PR Automation

GitHub MCP Server handles all GitHub operations. It connects to the GitHub API and creates pull requests with descriptions, labels, and reviewers.

How It Works Together

I invoke skill- /commit-guardian
    ↓
Skill summarizes changes, proposes commit message
    ↓
Hook intercepts git commit and runs checks
    ↓
Checks fail? → Hook blocks and returns errors. Skill guides Claude to fix and retry
    ↓
Checks pass? → Commit proceeds
    ↓
Skill invokes GitHub MCP Server
    ↓
MCP creates/updates PR
    ↓
Done - PR URL returned

Setting Up the Hook

The hooks configuration lives in .claude/settings.json. You can create this using /hooks. You can also define hooks inside Claude Skill. This hook will run during Claude Skill’s lifecycle.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python .claude/hooks/commit_guard.py"
          }
        ]
      }
    ]
  }
}

Our hook executes the script - .claude/hooks/commit_guard.py. Here’s the script structure.

#.claude/hooks/commit_guard.py
# Pre-commit quality gate - runs lint, typecheck, tests

import json
import subprocess
import sys

def detect_package_manager():
    """Returns npm, yarn, or pnpm based on lock files."""
    # ...

def run_checks():
    """Runs lint, typecheck, and tests. Returns results."""
    # ...

def main():
    raw = sys.stdin.read().strip()
    data = json.loads(raw)
    
    # Only intercept git commit commands
    if "git commit" not in data.get("tool_input", {}).get("command", ""):
        return 0
    
    results = run_checks()
    failed = [r for r in results if not r[1]]
    
    if failed:
        sys.stderr.write("Commit blocked - checks failed\n")
        return 2  # Block commit
    
    return 0  # Allow commit

if __name__ == "__main__":
    raise SystemExit(main())

Creating the Skill

I created the skill based on my requirements. My commit messages follow a standard format with conventional commits using type and scope. PRs need specific templates with changes, motivation, and testing sections. The skill defines these rules. Claude follows them exactly every time.

The skill lives at .claude/skills/commit_guardian/SKILL.md.

---
name: commit_guardian
description: Manages commit workflow with quality checks and automated PR creation. Use when committing code or creating pull requests.
allowed-tools:
  - Read
  - Edit
  - Write
  - Bash
---

# Commit Guardian Workflow

## Process

1. **Pre-Commit Summary**
   - List staged files
   - Summarize changes (2-3 lines)

2. **Commit Message**
   - Format: `type(scope): description`
   - Types: feat, fix, docs, style, refactor, test, chore
   - Under 72 characters

3. **Quality Checks**
   - Hook runs: lint, typecheck, tests
   - If fail: explain, fix, rerun
   - Repeat until pass

4. **PR Creation**
   - Get branch and target
   - Use GitHub MCP to create PR
   - Add title, description, labels, reviewers

## PR Template
```
## Changes
[What changed]

## Motivation
[Why needed]

## Testing
- [ ] Tests added/updated
- [ ] Manually tested
- [ ] All checks passing
```

Setting Up GitHub MCP

Install the GitHub MCP server to Claude Code. It handles all GitHub operations.

claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer YOUR_GITHUB_PAT"}}'

Testing the workflow- Commit to PR Skill

You can manually invoke skills using their name. I invoked /commit-guardian to test the workflow. Claude can also invoke skills automatically based on context.

As this is my daily routine, I customized this flow with skills. So that it can complete the flow just like me.

Get the Code

Above mentioned skill files, scripts are available at this GitHub Repo.

5. Automate Invoice Generation with Claude Skills

I work on small projects often. I track my hours, calculate totals, and fill the invoice template. Simple work, but it adds up.

So, I automated it using Claude Skills. The goal is straightforward. Track time while I work, calculate billable hours, and generate a ready-to-send invoice PDF.

The Flow:

Slash commands

I created slash commands to log start and end times. The commands live in .claude/commands/.

/start-work logs the start time. /stop-work logs the end time.

If you want, you can add /pause for breaks or customize commands for your workflow.

CLAUDE Skill

The Claude skill reads .work_log.json and totals hours for the selected period. It fills the invoice PDF template using the bundled script and generates the final invoice.

How it works

Get the Code

The invoice generation skill, slash commands, and scripts are available in the GitHub repo.

6. Top Claude Code skills

1. Superpowers – Skills that add structured workflow commands like brainstorm and execute plan to organize development tasks.

2. dev-browser - Claude skills to give your agent the ability to use web browser.

3. mcp-builder - Skills to create MCP servers

4. frontend-design - Skills to create production grade frontend design.

5. pdf-skills - Skills to do pdf operations.

6. Notion Skills - Skills that teach Claude how to work in Notion.

Want to build your own skills? Check out this article on creating custom skills.

Using Skill Creator

Claude Code has a built-in skill creator. Enable it in settings and describe what you need. Claude generates the skill.md and all the files for you.

Conclusion

We covered Claude Skills and two workflows I use daily for commit automation and invoice generation.

Skills turn repetitive work into reusable instructions. Combine them with hooks and MCP to build reliable automation. See how developers use Claude Skills in production to capture ML experiment results and prevent duplicate work.

If you have repeatable routines in your day-to-day work, you can likely automate them with Skills. Build one skill for your workflow and see how much time it saves.

Happy Learning!

They started with Tinker.

Tinker is an API for fine tuning large language models. The idea behind it is simple. You control the training logic. This includes your data, loss functions, and training loop. Tinker takes care of the hard parts like distributed GPU training, scheduling, and system reliability.

In simple terms, Tinker helps you fine tune models without worrying about infrastructure, while still giving you full control.

In this blog, I walk through:

1. What is Tinker

2. Why Tinker

3. Finetuning DeepSeek V3 with Tinker

4. Inference and Deployment Options

1. What is Tinker

Tinker is an API for fine tuning large language models.

Fine tuning means taking an existing model and training it on your own data. This is how a model learns a new style or task.

With Tinker, you still write the training logic. You decide how data is loaded, how loss is calculated, and how the training loop runs.

But you do not have to manage the infrastructure. You call the Tinker API from your local machine, and the training runs on Tinker’s GPUs.

The Tinker API has four functions:

2. Why Tinker

Fine-tuning LLMs typically falls into two extremes.

Manual fine-tuning

It gives you complete control. Your GPUs. Your CUDA setup. Your choice of libraries and optimizers. Every knob is yours to turn.

But so is every failure. Every compatibility issue. Every hour spent on infrastructure instead of actual training.

Platform-based fine-tuning:

It offers simplicity. just upload a dataset, click train, download weights. No infrastructure to manage, no code to write.

But you’re locked out of the training process entirely.

Tinker: The Middle Ground

Tinker fits in the right sweet spot between Manual Finetuning and Platform based Finetuning. It gives you control where it matters.

You define the datasets, loss functions, and training loops. Tinker handles the infrastructure headache like GPU setup, Distributed training, Memory management and Hardware failures.

Tinker gives you full control over fine-tuning without the infrastructure tax.

Both extremes come with some disadvantages, which makes Tinker Existence Valuable.

3. Finetuning DeepSeek V3 with Tinker API

Now let us finetune DeepSeek Model with Tinker API.

I send out the Dev Catch Up newsletter every week. Each item follows a clear style. It is short, simple, and focused on what actually matters. I read AI updates and releases, then rewrite them in my own voice.

I wanted to see if DeepSeek could learn this style.

So, I fine-tuned the model on my newsletter data. After training, it started picking up the Dev Shorts tone. Simple and Short sentences. No unnecessary hype.

Before fine tuning, the base model behaves like most LLMs. It uses bullet points, emojis, and phrases like “game changer” or “massive upgrade”. That is not how I write.

Let us now fine tune it step by step and see how the output changes.

Step 1: Install Tinker

!pip install tinker
!pip install torch
!pip install tinker_cookbook

Step 2: Set Your API Key

import os
os.environ["TINKER_API_KEY"] = "your-api-key-here"

Step 3: Import necessary packages

Tinker is the core training API. It runs the training on managed infrastructure.

Tinker Cookbook is an optional helper library. I am using it here for tokenization, chat formatting, and dataset conversion.

If you want, you can write tokenization and the rest from scratch without using Cookbook and work directly with the Tinker API.

import json
import time
import tinker
import torch
from tinker import types
from tinker_cookbook import renderers
from tinker_cookbook.supervised.data import conversation_to_datum
from tinker_cookbook.renderers import TrainOnWhat
from tinker_cookbook.tokenizer_utils import get_tokenizer
from tinker_cookbook import model_info
from tinker_cookbook.supervised.common import compute_mean_nll

Step 4: Connect to Tinker and see available models:

service_client = tinker.ServiceClient()
capabilities = service_client.get_server_capabilities()

print(”Available models:”)
for model in capabilities.supported_models:
    print(f”  {model.model_name}”)

Step 5: Select the base model to finetune

MODEL_NAME = “deepseek-ai/DeepSeek-V3.1”

This is the base model we are going to fine-tune. The model's name must match one of the available models returned by the Tinker API.

Step 6: Configure LORA Finetuning Parameters

BATCH_SIZE = 8
LEARNING_RATE = 2e-5
LORA_RANK = 32
MAX_LENGTH = 4096
NUM_EPOCHS = 10

LEARNING_RATE = 2e-5 is 0.00002. - Start conservative for large models.

LORA_RANK = 32 - Controls the adapter size. Higher means more capacity but slower training.

NUM_EPOCHS = 10 - means model go through the dataset 10 times.

Step 7: Load Tokenizer and Renderer

tokenizer = get_tokenizer(MODEL_NAME)
renderer_name = model_info.get_recommended_renderer_name(MODEL_NAME)
renderer = renderers.get_renderer(renderer_name, tokenizer)

The tokenizer converts text into tokens. The renderer defines how chat messages are formatted before they are sent to the model.

Step 8: Prepare the Dataset for Training

My dataset is a JSONL file.

The user message contains raw content scraped from release pages. The assistant message contains the Dev Shorts newsletter style.

I prepared around 100 rows in total. Each row follows this format. For this walkthrough, I am using a small sample of 16 rows.

{
  "messages": [
    {
      "role": "user",
      "content": "Rewrite in Dev Shorts newsletter style. 
We are introducing GPT‑5.2, the most capable model series yet for professional knowledge work.

Already, the average ChatGPT Enterprise user says⁠ AI saves them 40–60 minutes a day, and heavy users say it saves them more than 10 hours a week. We designed GPT‑5.2 to unlock even more economic value for people; it’s better at creating spreadsheets, building presentations, writing code, perceiving images, understanding long contexts, using tools, and handling complex, multi-step projects.

GPT‑5.2 sets a new state of the art across many benchmarks, including GDPval, where it outperforms industry professionals at well-specified knowledge work tasks spanning 44 occupations."
    },
    {
      "role": "assistant",
      "content": "OpenAI has launched GPT 5.2. It is better at creating spreadsheets, building presentations, writing code, understanding images. It can work with long context. It also uses tools more effectively and handles multi-step work with more accuracy. Read OpenAI’s GPT 5.2 post for more details."
    }
  ]
}

Step 9: Load the Dataset

DATASET_PATH = "dataset.jsonl"

training_data_raw = []
with open(DATASET_PATH, "r") as f:
    for line in f:
        training_data_raw.append(json.loads(line.strip()))

print(f"Loaded {len(training_data_raw)} examples")

Step 10: Convert the data to training format

conversation_to_datum - This function converts each conversation into a format Tinker can use for training.

TrainOnWhat.ALL_ASSISTANT_MESSAGES - It tells Tinker to only learn from assistant responses, not user messages.

training_data = [
    conversation_to_datum(
        ex["messages"],
        renderer,
        MAX_LENGTH,
        TrainOnWhat.ALL_ASSISTANT_MESSAGES,
    )
    for ex in training_data_raw
]

Step 11: Create Training Client

training_client = service_client.create_lora_training_client(
    base_model=MODEL_NAME,
    rank=LORA_RANK,
)

print("Training client created")

Step 12: Train the Model

Tinker has 4 core functions. The training loop uses two of them.

• forward_backward() - compute gradients

• optim_step() - update weights

n_batches = len(training_data) // BATCH_SIZE

for epoch in range(NUM_EPOCHS):
    print(f"\nEpoch {epoch + 1}/{NUM_EPOCHS}")
    
    for batch_idx in range(n_batches):
        t_start = time.time()
        
        # Learning rate decay
        step = epoch * n_batches + batch_idx
        total_steps = NUM_EPOCHS * n_batches
        lr_mult = max(0.0, 1.0 - step / total_steps)
        current_lr = LEARNING_RATE * lr_mult
        
        adam_params = types.AdamParams(
            learning_rate=current_lr,
            beta1=0.9,
            beta2=0.95,
            eps=1e-8,
        )
        
        # Get batch
        batch_start = batch_idx * BATCH_SIZE
        batch_end = batch_start + BATCH_SIZE
        batch = training_data[batch_start:batch_end]
        
        # Training step
        fwd_bwd_future = training_client.forward_backward(batch, loss_fn="cross_entropy")
        optim_step_future = training_client.optim_step(adam_params)
        
        fwd_bwd_result = fwd_bwd_future.result()
        optim_step_future.result()
        
        # Compute loss
        logprobs = [out["logprobs"] for out in fwd_bwd_result.loss_fn_outputs]
        weights_list = [d.loss_fn_inputs["weights"] for d in batch]
        mean_nll = compute_mean_nll(logprobs, weights_list)
        
        elapsed = time.time() - t_start
        print(f"  Batch {batch_idx + 1}/{n_batches} | NLL: {mean_nll:.4f} | LR: {current_lr:.2e} | Time: {elapsed:.2f}s")

print("\nTraining complete")

The loss (NLL) should decrease as training progresses.

Note: The dataset size and epochs shown here are for demonstration. I actually finetuned with more rows and higher epochs to get the model to pick up the style properly.

Step 13: Save Checkpoint

This uses Tinker's third function.

save_weights_for_sampler() - It stores the checkpoint on Tinker's servers.

final_path = training_client.save_weights_for_sampler(name="final").result().path
print(f"Final checkpoint: {final_path}")

Step 14: Test the Finetuned Model

Finally, test the finetuned model using Tinker’s fourth function- sample().

test_client = service_client.create_sampling_client(model_path=final_path)

test_input = (
    "The Gemma is a family of generative AI models designed for tasks like question answering, summarization etc. It is a family of open models from Google. Gemma recently crossed 100 million downloads and has a growing community with tens of thousands of model variants created by developers. Google has now introduced Gemma 3, a new set of lightweight open models built on the same research used for Gemini 2.0. These models are designed to run efficiently on devices like phones, laptops, and workstations. Gemma 3 is available in multiple sizes including 1B, 4B, 12B, and 27B. Gemma 3 supports text and image reasoning, a 128k token context window, function calling, and structured outputs. It also offers support for more than 140 languages and includes official quantized versions to improve performance while reducing compute requirements."
)

STYLE_PREFIX = (
    "Rewrite in Dev Shorts newsletter style."
)

convo = [
    {
        "role": "user",
        "content": STYLE_PREFIX + "\n\n" + test_input
    }
]

model_input = renderer.build_generation_prompt(convo)

result = test_client.sample(
    prompt=model_input,
    num_samples=1,
    sampling_params=types.SamplingParams(
        max_tokens=200,
        stop=renderer.get_stop_sequences(),
        temperature=0.2,
    ),
).result()

parsed_message, _ = renderer.parse_response(result.sequences[0].tokens)
output = parsed_message["content"]

print("INPUT:")
print(test_input)
print("\nOUTPUT:")
print(output)

The finetuned model writes in the style we finetuned.

Output:

Google released Gemma 3. It is a set of open models for tasks like question answering and summarization. It has a 128K token context window and supports text and image reasoning. It is designed to run on phones, laptops, and workstations. It supports over 140 languages. Check Google’s Gemma 3 for more details.

Step 15: Download the finetuned model weights

import urllib.request

sc = tinker.ServiceClient()
rc = sc.create_rest_client()
future = rc.get_checkpoint_archive_url_from_tinker_path("tinker://8c8-------2d0bd:train:0/sampler_weights/final")
checkpoint_archive_url_response = future.result()
urllib.request.urlretrieve(checkpoint_archive_url_response.url, "deepseek_finetuned.tar")

We tested the fine-tuned model using Tinker. Now let us see how to use the fine-tuned weights outside Tinker.

4. Inference and deployment options

As we can download finetuned weights - LoRA adapters, we can also use it outside the Tinker platform.

1. Load the LoRA adapter using Hugging Face PEFT

You can load the LoRA adapter on top of the base model using HuggingFace PEFT. and use for inference.

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained("deepseek-ai/DeepSeek-V3.1")
tokenizer = AutoTokenizer.from_pretrained("deepseek-ai/DeepSeek-V3.1")
model = PeftModel.from_pretrained(base_model, "./deepseek_finetuned")

prompt = "Rewrite in Dev Shorts newsletter style.\n\nOpenAI released GPT-5..."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

2. Run the model with vLLM for fast inference

You can run the base model with the LoRA adapter using vLLM for fast inference.

from vllm import LLM
from vllm.lora.request import LoRARequest

llm = LLM(model="deepseek-ai/DeepSeek-V3.1", enable_lora=True)

output = llm.generate(
    "Rewrite in Dev Shorts newsletter style.\n\nOpenAI released GPT-5...",
    lora_request=LoRARequest("devshorts", 1, "./deepseek_finetuned")
)
print(output[0].outputs[0].text)

Note on hardware requirements

Running large models using Hugging Face or vLLM requires significant GPU memory. Make sure your hardware can handle the base model size.

If you do not want to manage infrastructure, you can also host the model on third party platforms that support LoRA adapters.

Conclusion

Tinker does one thing well. It lets you focus on training behavior instead of infrastructure.

If your goal is to fine tune models, Tinker is worth trying. You stay close to the training loop. You can see how the model changes at each step. And you can still take the weights and run them anywhere you want.

I hope this blog gave you a clear idea of what Tinker is and how it works.

See you in the next Bytes blog,

Until then, happy learning and happy holidays!!!

I have been using it inside Cursor for a few weeks. Opus 4.5 handled the coding work with ease. Cursor managed the agents and kept them running side by side. Together they cut my build time almost in half.

My iteration cycle changed as well. Most tasks worked on the first try. When something failed, the fix was fast. Less back and forth. More time to build.

This guide captures my workflow with Cursor and Opus 4.5 while building a real time application.

What we will cover

1. Claude Opus 4.5 features

2. Cursor’s latest features

3. A developer workflow with Cursor and Opus 4.5

4. What I noticed in the code while using Opus 4.5

5. Cursor with other models

Let us start.

1. Claude Opus 4.5

Here is a quick view of what Opus 4.5 offers. I grouped the model spec and the capabilities so you can see both sides at once.

Opus comes with its own strengths, but it is not the best choice for every task. Other models perform better in some areas.

When it comes to multilingual tasks, Gemini performs better than Opus. For visual tasks, GPT takes the lead.

2. Cursor Features

Here are the Cursor features that helped the most during the build. I grouped them so you can see how all in one place.

Both tools bring their own strengths. When used together, the workflow becomes faster and easier.

Here is the cursor + opus 4.5 workflow for building an application.

3. Cursor + Opus 4.5: The new developer workflow

The application I built is a small API monitoring tool.

What it does :- Captures all API calls from my local apps and shows them in a clean UI.

Why I built it :- DevTools works, but shows everything like network requests, console logs, DOM changes. Too much noise when I just want to see API calls.

How it helps :- Clean view of only API requests and responses. No clutter. Makes debugging faster.

I will start by pre-cursor setup.

Step 1: Pre-Cursor Setup

mkdir api-monitor-demo
cd api-monitor-demo
git init
cursor .

Step 2: Set Up Rules Before Writing Code

Cursor supports rules. These rules act like project standards. Once you set them, Cursor follows them whenever needed.

There is a Cursor rules repo on GitHub with examples for many languages.

I copy the rules and send them to an agent. I ask the agent to create the rule files. I keep sending prompts for creating rules for both frontend and backend. Cursor queues the messages and completes each task one by one while I plan the rest of the work.

Create Rules Folders and Files

Prompt to the Agent:

• Create .cursor/rules/ folder

• Create core.mdc inside .cursor/rules with below content.

• Create backend.mdc inside .cursor/rules with below content.

• Create frontend.mdc inside .cursor/rules with below content.

Sample content for core.mdc

---
description: Core project standards
globs:
alwaysApply: true
---

# Standards

- TypeScript strict mode
- Never use `any` — use `unknown` and narrow
- Never write `// ... rest of code` placeholders
- Always provide complete implementations
- Use Zod for runtime validation
- Log errors with context: `console.error(’[Component]’, error)`

Start with a few rules. Add more only when you see repeated mistakes. Keep the tab open and update it as you build.

Step 3: Plan with Opus 4.5 (Use Commands for Planning)

Cursor has an Ask Mode for read only conversations. It answers questions but does not touch the code.

I used Ask Mode at first, but I often forgot to switch back to Agent Mode when I wanted to make code changes. Then I had to repeat the prompt in Agent Mode.

To avoid this, I use a small planning command. I run this command in Agent Mode, but it does not make any code changes.

Create a file at .cursor/commands/planonly.mdc with this content:

#planonly.mdc

Do not update any code. Instead:
- Explain the approach
- List options with pros and cons
- Highlight potential challenges
- Ask clarifying questions if the request is unclear
- Respond based on prompt

This works like a clean planning mode inside Agent Mode. I use it when I want Cursor to think through the problem without touching the repo.

Cursor gives a few example commands on its page. You can create your own commands based on your workflow.

I keep a small set of commands that I use often.

For any new project,

I think through the design with Opus first. Once the design is clear, I ask it for the detailed prompts to build the frontend and backend.

Opus works like a prompt builder in this stage.

Since it knows the full context, it gives detailed prompts for each part. I paste them into different agents, and they start to build in parallel.

Step 4: Building the app with cursor parallel agents

Once I had the prompts from Opus, I sent them to separate agents.

This is where Cursor and Opus change the way we build. Instead of working on one part at a time, you can run many agents in parallel. Each agent focuses on a single part of the project.

For this app, I used three agents: frontend, backend, and infra.

Backend Agent:

Prompt:- Build the backend proxy server in src/server/ with these requirements:

[backend requirements here]

Frontend Agent

Prompt:- Build the React UI in src/ui/ with these requirements:

[frontend requirements here]

Infrastructure Agent

Prompt:- Set up project infrastructure

[infra requirements here]

All three agents run at the same time. This is the folder structure I got for the API monitoring app.

Watch three agents build the API Monitoring app in parallel. Backend, frontend, and infrastructure - all at the same time

The API monitoring tool was a small project built locally from scratch, so running all agents in the same folder worked fine.

But in bigger projects and git repos, the number of files and changes grows, and conflicts become more likely. This is where git worktrees help.

Working with existing GitHub repo

Git worktrees let you work on multiple branches at the same time. Each agent gets its own workspace. No overlap. No risk of one agent overwriting the work of another. Also, multiple feature development can be done at the same time.

In that case, I start by creating feature branches with git worktrees.

git worktree add ../ui -b feature/ui
git worktree add ../api -b feature/api

I open each worktree in its own editor window. Then I ask Opus to read the code and understand the repo. Then each agent starts to work in its own folder.

When the work is done, I merge the feature branch back into main. Cursor shows the diffs clearly, and the review tools help catch mistakes before the merge.

Code review

Cursor has a built-in review flow. It helps you check the changes made by the agents. It shows a simple diff, and you can choose which changes to accept.

Cursor can review after each commit, include untracked files, or include submodules.

You can also create a command for code review and use it in chat.

You can also use tools like Coderabbit AI to review your code inside IDE.

4. What I noticed in the code while using Opus 4.5

Here are some things I noticed in the code while using Opus 4.5.

1. Handled complex logic without breaking the flow

2. Delivered clean code in a single prompt in many cases

3. Kept the structure stable across long tasks

4. Produced modular and efficient code by default

5. Wrote clear and consistent UI components

6. Created well-structured API endpoints

7. Used predictable naming and patterns across files

8. Generated self-explanatory code that needed fewer comments

5. Cursor with other models

After working with cursor for many months, I switch between models based on the kind of work I am doing. Each one has a strength.

Conclusion

We looked how Cursor agents with Opus 4.5 help speed up development. If you are using Cursor, try with agents - Opus 4.5 and git worktrees. It keeps the work organized and makes it easy to build features in parallel.

This setup is not about changing everything you do. It just gives you a smoother way to move through your work.

Next time you start a project, try this: Open parallel agents. Give each one a clear task. Let them run while you plan what’s next. You’ll finish faster than you expect

Happy Learning!

We are now moving to the next stage of agent-based coding. We can use parallel agents to work on many features and fixes at the same time inside the same repo.

Claude Code and Cursor support parallel agents. They use Git work trees to give each agent its own space to work. You can follow the same approach by creating work trees in your project.

Let us first understand what Git worktrees are and how they help with parallel coding.

1. What is a Git worktree

2. Git worktree Vs Git Clone

3. Git worktree Commands

4. Claude Code’s Parallel Agents with Git worktrees

5. Cursor’s Parallel Agents with Git worktrees

6. CodeRabbit’s Git worktree runner

1. What is a Git worktree

Git worktree is a feature in Git. Before we see Git worktree, let us see the normal Git flow.

The normal Git flow

• You have one working folder.

• You have one active branch.

• Switching branches changes all files in that folder

my-app/
├── src/
├── README.md
└── .git/

When you run git checkout “feature-abc”, the whole folder switches to that branch.

The Git work tree flow

• Work trees let you have many working folders from the same repo.

• Each folder can have its own branch.

• You can work in all of them at the same time without switching anything.

In simple words, you can work in parallel without switching branches.

my-app/                    
├── src/
├── README.md
└── .git/

my-app-feature-a/          ← Worktree 1 (feature-a branch)
├── src/
├── README.md
└── .git                   ← File points to main repo

my-app-feature-b/          ← Worktree 2 (feature-b branch)
├── src/
├── README.md
└── .git                   ← File points to main repo

2. Git worktree Vs Git Clone

The points above explain the concept. But the commands make it crystal clear.

This is what we do in a normal clone and what we do when we use work trees.

3. Git Worktree Commands

There are a few basic Git work tree commands you will use often.

1. Create worktree

# Create a work tree and a new branch
git worktree add <worktree-path> -b <new-branch-name>

# Example
git worktree add ../add-header -b feature/add-header


# Create a work tree from an existing branch
git worktree add <worktree-path> <branch-name>

# Example
git worktree add ../ui-changes feature/ui-changes

2. List worktree

# list all active work trees
git worktree list

3. Remove worktree

# remove a work tree
git worktree remove <worktree-path>

# Example
git worktree remove ../add-header

One branch per Worktree Rule

Git has a simple rule for work trees. One branch can live in only one work tree at a time.

If the branch is already used in a work tree, Git will block you from using it again. See the screenshot below.

4. Claude Code with Git worktrees

Claude Code can run parallel agents when you use Git work trees. Each work tree has its own folder and its own branch, so Claude can work on many tasks at the same time.

I was building a Gmail mail hub for my personal use. I had ui changes and oauth work going on at the same time.

Here is how I used Claude Code with work trees to build two features at the same time.

1. Created a new worktree for ui changes

git worktree add ../ui-changes -b feature/ui-changes

2. Created another worktree for oauth integration

git worktree add ../oauth-integration -b feature/oauth-integration

After creating them, I listed the work trees to make sure everything was set:

You can also see the separate folders for each branch.

Now Claude Code can work across these branches without switching, as we have separate folders.

I worked on ui changes and oauth integration at the same time using Claude Code.

The video below shows how it works in real time.

5. Cursor’s Parallel Agents with Git Worktrees

Cursor makes it easy to run parallel agents by using Git work trees in the background.

You can start by selecting a work tree and choosing many models for the same task, as shown in the image. Cursor will run the same prompt across all the selected models at once.

After you submit the prompt, Cursor shows one card for each model. You can click through the cards and see how each model changed the code.

When you like one of the versions, you can click Apply. Cursor will bring those edits into your checked out branch.

You can also customize worktrees by editing .cursor/worktrees.json file.

All commands you add under setup-worktree will run inside the work tree during setup.

You can see all active worktrees anytime by running git worktree list. If you want to see Cursor created worktrees in your SCM panel, you can enable the git.showCursorWorktrees setting.

6. Git Worktree Runner - gtr

If you want a simpler way to handle worktrees, CodeRabbit offers a helper tool called Git Worktree Runner. It makes it easy to create, open, and manage worktrees with short commands. If you use worktrees often, this tool saves a lot of typing.

You can find it here: CodeRabbit’s Git Worktree Runner

Here is how you can install and use it.

# Installation

git clone https://github.com/coderabbitai/git-worktree-runner.git
cd git-worktree-runner
sudo ln -s “$(pwd)/bin/git-gtr” /usr/local/bin/git-gtr

# Usage

cd ~/your-repo                              # Navigate to git repo
git gtr config set gtr.editor.default cursor    # One-time setup
git gtr config set gtr.ai.default claude        # One-time setup

# Daily workflow
git gtr new my-feature                          # Create worktree
git gtr editor my-feature                       # Open in editor
git gtr ai my-feature                           # Start AI tool
git gtr rm my-feature                           # Remove when done

This table gives a quick comparison of Git worktree commands and the matching gtr commands.

Conclusion

We looked at Git worktrees and how they help with parallel agentic coding.

Worktrees let you build many features at the same time without switching branches or creating extra clones.

Tools like Claude Code, Cursor make it even better by linking every agent to its own work tree. This keeps your work clean, safe, and fast.

Once you start using work trees, it is hard to go back to the old single folder flow. You get more focus, more speed, and fewer mistakes with this new workflow. Try creating a few work trees for your next project and see how simple it feels to work on many features at the same time.

If you use any agent-based coding tool, work trees will become a natural part of your daily workflow.

Try now and let me know how it helps in your workflow!

Happy Learning!

During the LLM wave, we saw models that could convert text to speech. Now, in the agent era, voice agents are taking the spotlight. Out of every ten calls I get, at least one is from an automated voice agent promoting something. The conversational AI space is growing fast.

So, let’s explore how to build our own voice agent.

In this blog, we will cover,

1. Getting Started with Voice Agents

2. Frameworks for Voice Agents

3. Building voice agents with code -OpenAI’s Agent SDK

4. Building voice agents without code - Voice Flow, Retell AI, Vapi

5. Further Reading: TTS, STT, and Speech-to-Speech Models and APIs

1. Getting Started with Voice Agents

We have come a long way from simple text-to-speech models. Voice agents today can talk, reason, and respond in real time. It’s a big step forward in conversational AI.

A voice agent is a virtual assistant that holds natural conversations. It works over phone calls or websites. The agent listens to speech, processes it using language models, takes action, and responds in a human-like voice.

These agents can handle real tasks. They schedule appointments, answer customer questions, and make sales calls. They can call APIs, maintain context across conversations, and connect with other systems to get things done.

You can build voice agents in two ways.

Pipeline Method

The first way is a kind of pipeline approach using separate models:

• Speech-to-text (STT)

• A language model for reasoning and tool calls,

• Text-to-speech. (TTS)

Example speech-to-text models: Whisper, Deepgram, AssemblyAI

Example text-to-speech models: gpt-4o-mini-tts, Google TTS, ElevenLabs, Sonic 3

Speech to Speech Method

The second approach uses a single speech-to-speech model. This removes the hand-off delays between STT and TTS models, making conversations smoother. This is faster and feels more natural.

Example speech-to-speech models: GPT Realtime Models, Gemini Models ,

Now that you understand how voice agents work, here’s how to choose the right approach for your project.

2. Frameworks for Voice Agents

As voice agents become more common, new frameworks are coming up to build and launch them faster.

Like other AI agents, voice agents also have two types of frameworks - code and no code.

Code frameworks give developers full control. They let you handle speech, logic, and real-time audio in your own way.

No code frameworks help teams move faster. You can design, test, and launch voice agents with visual tools.

3. Building Voice Agents with code - OpenAI’s Agent SDK

Let us first build a simple voice agent using OpenAI Agent SDK.

This voice agent can search for files on your laptop. You can ask it to find files by name in specific folders like Downloads, Documents, or Desktop. Just speak naturally, and it will search and tell you what it found.

How it works

This voice agent follows a five-step process from input to output.

1. Sound Device - This Python library captures audio from your microphone.

2. Voice Pipeline - It converts your speech into text using a speech-to-text model.

3. Agent SDK - The agent reads the text, executes the logic, and generates a response.

4. Voice Pipeline - It converts the agent’s text response back into natural voice audio.

5. Sound Device - The library plays the voice response through your speakers.

The entire flow happens in real time. You speak, the agent processes, and responds with voice.

Here is the code

1. Install required packages

pip install openai-agents[voice] sounddevice scipy 

2. Setting Up the File Search Tool

import asyncio
import os
import sounddevice as sd
from scipy.io import wavfile
from agents import Agent, function_tool
from agents.voice import AudioInput, SingleAgentVoiceWorkflow, VoicePipeline

@function_tool
def search_files(pattern: str, directory: str = “home”) -> str:
    “”“Search for files matching a pattern in common directories.”“”
    import glob
    
    BASE_DIR = r”C:\Users\YourUsername”  # Change this
    
    # Map common folder names
    folder_map = {
        “downloads”: “Downloads”, “documents”: “Documents”,
        “desktop”: “Desktop”, “pictures”: “Pictures”, “home”: “”
    }
    
    # Determine search directory
    dir_lower = directory.lower().strip()
    if dir_lower in folder_map:
        folder_name = folder_map[dir_lower]
        search_dir = os.path.join(BASE_DIR, folder_name) if folder_name else BASE_DIR
    else:
        search_dir = directory
    
    # Search for files
    files = glob.glob(f”{search_dir}/**/*{pattern}*”, recursive=True)[:10]
    
    if not files:
        return f”No files found matching ‘{pattern}’”
    
    result = f”Found {len(files)} file(s):\n”
    for f in files:
        result += f”- {f}\n”
    return result

3. Creating the Agent with tool access

agent = Agent(
    name=”FileSearchAssistant”,
    instructions=”You help users search for files. Be concise.”,
    model=”gpt-4.1”,
    tools=[search_files],
)

4. Capturing User Audio

def record_audio(duration=8, samplerate=24000):
    “”“Record audio from microphone.”“”
    print(f”Recording for {duration} seconds... Speak now!”)
    
    recording = sd.rec(int(duration * samplerate), samplerate=samplerate, 
                      channels=1, dtype=np.int16)
    sd.wait()
    
    wavfile.write(”user_input.wav”, samplerate, recording)
    return recording.flatten()

5. Processing Audio Through Pipeline

async def process_voice():
    # Capture voice
    audio_data = record_audio(duration=8)
    
    # Create pipeline and process
    pipeline = VoicePipeline(workflow=SingleAgentVoiceWorkflow(agent))
    audio_input = AudioInput(buffer=audio_data)
    result = await pipeline.run(audio_input)
    
    return result

6. Playing Agent Response

async def main():
    print(”Voice Agent - File Search”)
    
    # Process voice through pipeline
    result = await process_voice()
    
    # Play response
    print(”Playing response...”)
    player = sd.OutputStream(samplerate=24000, channels=1, dtype=np.int16)
    player.start()
    
    output_audio = []
    async for event in result.stream():
        if event.type == “voice_stream_event_audio”:
            player.write(event.data)
            output_audio.append(event.data)
    
    player.stop()
    
    # Save output
    if output_audio:
        agent_audio = np.concatenate(output_audio)
        wavfile.write(”agent_output.wav”, 24000, agent_audio)
    
    print(”Done!”)

if __name__ == “__main__”:
    asyncio.run(main())

To run:

python voice_agent.py

Below is an example conversation

I asked: “Search for MCP text file in the Applications folder”

Listen to my voice input

The agent searched through my Applications directory and found matching files.

Listen to agent’s response

Choosing Your Transport Method

Latency matters in voice agents. OpenAI’s Realtime API offers two low-latency transport methods.

1. WebRTC (Client-side)

• Best for browser-based voice agents.

• Peer-to-peer connection with low latency.

• Direct audio streaming between user and OpenAI.

2. WebSocket (Server-side)

• Best for phone call systems.

• More control over the call flow.

• Required integrations like Twilio.

The OpenAI Agents SDK automatically picks the right transport. It uses WebRTC in browsers and WebSocket for server-side applications.

Building a Phone Call Agent

For phone calls, you need a telephony service like Twilio. The architecture looks like this:

How it works:

1. User calls a Twilio phone number.

2. Twilio connects to WebSocket.

3. WebSocket forwards streaming audio to OpenAI.

4. The Realtime OpenAI API responds back in audio.

5. Audio streams back through the same path.

OpenAI provides a complete demo on GitHub showing how to build a phone call agent with Twilio.

4. Building Voice Agent without Code - Vapi.ai

Not everyone wants to write code. Sometimes you just need to build the agent fast. That’s where platforms like Voiceflow and Vapi comes into the picture.

Building with Vapi:

Vapi’s platform is self-explanatory. You can explore on your own. But here’s what I built as an example.

I created a voice assistant called “Abigail” that checks domain availability. You call the assistant, ask if a domain name is available, and it tells you in real-time. Simple use case to show how Vapi works.

1. Create an Assistant

I created an assistant called “Abigail” and configured the basics like model, voice, and first message.

2. Add Tools

You can add available tools and integrations. Slack, Google Sheets, API calls etc.

I integrated MCP Tool to check domain availability. Tools let your agent take actions during calls.

3. Configure Call Settings

Vapi supports both inbound and outbound calls. You can configure phone numbers for either direction.

Inbound - Agent receives calls. Users call a phone number, and your agent answers.

Outbound - Agent makes calls. The agent dials phone numbers to reach users.

4. Test and Publish your Voice Assistant

I tested it with a call. Here’s the transcript.

You can connect Vapi with n8n agentic workflow. We’ll save that topic for next blog. If you want to see how it works now, check out this video that walks through the vapi and n8n setup.

Building with Voiceflow: FAQ Agent

Voiceflow is another no-code platform for voice agents. It’s drag, drop, and configure.

I built an FAQ agent called “Ellie” for Dr. Jones Clinic. The agent answers common questions about consultation hours, appointments, insurance, and services.

1. Create the Agent

I started with a new agent and named it “Ellie - The FAQ Agent.”

I did set up a greeting message. The Start block connects to the Agent block. That’s the basic flow.

2. Add Knowledge Base

I went to the Knowledge Base section and created a data source called “Appointment & Scheduling.” Added FAQs as text content.

The “Ellie - The FAQ Agent” can now read this knowledge base and respond to user’s questions.

3. Connect a Phone Number

I went to Interfaces > Telephony > Phone numbers

I added a Twilio number. Now the agent can receive calls.

4. Test and Publish

I talked to Ellie. Asked about insurance services. She answered using the knowledge base. Here is the transcript.

Other platforms like Retell AI and Synthflow offer similar capabilities. The setup is mostly the same - configure, connect, and deploy.

Here’s a customer support agent I built in Retell AI

5. Further Reading: TTS, STT, and Speech-to-Speech Models and APIs

Building voice agents means choosing the right models. Here are resources to explore.

Speech-to-Speech Models:

• Speech to Speech Model Comparison

• 8 Best Speech to Speech APIs

Speech-to-Text (STT):

• Opensource Speech to Text Models

• Ten Speech to Text Models Tested

• Speech to Text APIs

Text-to-Speech (TTS):

• TTS Leaderboard on Hugging Face

• Open-Source Text to Speech Models

• Hugging Face Text to Speech Models

These links will help you pick the right models for your voice agent. Compare costs, latency, accuracy, and pick what works for you.

Conclusion

We covered two ways of building voice agents.

• Code frameworks like OpenAI SDK,

• No-code platforms like Vapi, Voiceflow

Code gives you control. No-code gives you speed. Pick what fits for you.

Start small. Build one voice agent. Test it and see what works.

Voice AI is here. The tools are ready. Now it’s your turn to build one.

Happy Building!

When you build an agent, the demo usually looks smooth. But once you run it in production, new challenges appear around safety, memory, recovery, and control.

The conference focused on what we need to consider before moving agentic apps to production. Below are the five areas that were discussed the most. That’s exactly what we’ll cover in this blog.

1. Guardrails

2. Memory Management

3. Error Handling and Recovery

4. Human in the Loop

5. Observability and Monitoring

If you are moving your agentic app to production, make sure you can confidently say yes to these questions.

1. Guardrails

If you ask an AI chatbot for something harmful, it will refuse. That is a guardrail which keeps the system safe, ethical, and within limits.

Guardrails act as a shield for agentic apps. They protect the agent from bad inputs and make sure it responds in the right way. In simple terms it defines the boundaries for an agent’s behavior. They keep it safe, prevent unwanted actions, and ensure it only operates within its intended scope.

Why Guardrails

In real-world setups, guardrails don’t stop at inputs and outputs. They extend across multiple layers to control how agents act, decide, and interact with tools or users. Each layer adds safety and stability to the system.

Tools and Frameworks for Guardrails

There are two main ways to add guardrails when taking an agentic system to production.

You can use the built-in guardrails that come with your agent framework or integrate separate libraries for more control and compliance.

Frameworks like LangGraph and OpenAI Agent SDK already include basic checks such as input moderation, safe tool access, and retry logic. For most apps, these are enough.

If you need deeper validation, you can plug in external toolkits built for strong control.

• Guardrails AI is a Python framework. It helps build reliable and safe AI applications. It works by adding input and output “guards” around your LLM calls. These guards detect and reduce different types of risks in real time, such as toxic language, personal data leaks or exposed secrets.

• NVIDIA NeMo Guardrails is an open-source toolkit by NVIDIA. It lets you add programmable guardrails to your AI Apps. It works by layering “rails” between your application logic and the LLM. It controls how the model behaves, what it says, and what actions it takes.

• Microsoft Presidio is an open-source framework. It focuses on detecting and redacting personal or sensitive data (PII) in text and images. It has options for connecting to external PII detection models.

• Langchain Guardrails provide built in guardrails. They can detect sensitive information, enforce policies, validate outputs, and prevent unsafe behaviors before they cause problems.

• OpenAI Agents SDK includes built-in guardrails for both inputs and outputs. These run alongside your agents to validate and enforce safe behavior in agentic apps.

• OpenAI Guardrails is a ready-to-use toolkit for adding safety and compliance checks to your LLM apps. You can select prebuilt guardrails such as Mask PII, Moderation API, or Jailbreak Detection directly from the dashboard, export them as a JSON config file, and use them in your application.

You can also build your own guardrails for your app. Think of them as simple toolkits that protect your agentic system and keep it under control.

2. Memory Management

When you chat with ChatGPT, it remembers what you said earlier. That is what memory does. It helps the system stay consistent and feel more human.

Memory helps the agent retain context, recall past steps so it can respond properly.

An agent without memory starts from zero every time. With memory, it remembers what happened, adapts to the user, and gets smarter with every run.

The Redis blog explains this well. Here’s how short-term and long-term memory connect with the agent, tools, and LLM.

Types of Memory

Agents work with two types of memory.

• Short-term memory – Keeps track of recent steps or the current task.

• Long-term memory – Holds information that should last beyond a single run. This could be user details, preferences, or past interactions.

Different frameworks handle memory in their own ways.

In LangGraph, every message is saved in the state variable as an AIMessage or HumanMessage. This helps the agent maintain context during the current session. When the agent restarts, it starts fresh. That’s short-term memory.

To make it remember across sessions, you need long-term memory. Here, past messages or summaries are stored externally, usually in a vector database or memory store. This allows the agent to retrieve relevant context from older sessions when needed.

The LangChain video explains this Agent memory well.

Why Memory Matters

• Most LLMs are stateless. They don’t remember what happened earlier unless we tell them. In real-world apps, that’s not enough.

• Agents need memory to recall user preferences, track progress, and carry context across steps. Without it, they repeat questions and lose continuity.

• Without good memory design, too much context slows down responses, increases cost, and can even confuse the model.

Tools and Frameworks for Memory

When you’re building agentic apps, you don’t have to invent your memory layer from scratch. There are tools and frameworks ready for use.

• Mem0: A self-improving memory layer for AI agents that stores user preferences and past sessions. It supports short- and long-term memory.

• Graphiti: An open-source Python framework for building temporally aware knowledge graphs for agents. It captures relationships over time, enabling agents to reason beyond vector store.

• Zep: Zep is a memory platform for AI agents. It learns from user interactions. It builds a time-based knowledge graph that helps agents give accurate and personalized answers. Over time, it keeps learning and improving user experience. It is powered by Graphiti.

3. Error Handling and Recovery

When you run agentic apps in production, things will break. A tool call might fail, an API might timeout, or the model might return something you didn’t expect. Error handling and recovery is about catching those issues, dealing with them properly, and keeping the agent running safely.

Why It Matters

Agentic apps rarely fail because of big bugs. They fail because of the small things like a bad response, or a tool call that never returns. One silent error can stop the whole workflow. Without a plan, the agent either crashes or keeps looping endlessly trying to fix itself.

Good error handling makes your agent resilient. It helps the agent fail safely and continue from where it left off.

How to Handle Errors in Production

• Retry and fallback - Add retry logic for every tool or API call and have a fallback plan when retries fail.

• Save progress - Use checkpoints to save the agent’s state so it can resume after failure.

• Validate outputs - Always check if the model’s response or tool output is valid before using it.

• Add a human step when needed - Some errors need manual review. Don’t let the agent keep guessing.

• Log and monitor failures - Track the errors. This helps you fix recurring issues early.

4. Human in the Loop (HITL)

Human in the Loop (HITL) adds a human step inside the agent’s workflow. The agent pauses, waits for human input or approval, and then continues. It keeps humans involved at key moments and lets them guide the agent when needed.

Why It Matters

Agents can automate a lot, but not everything should run on autopilot. When a task involves compliance, sensitive data, or critical actions, a human check adds safety. It keeps the system reliable.

How to Add HITL in Production

Many frameworks support adding human-in-the-loop steps directly into your workflows.

1. You can add a LangGraph Human in the Loop step using the interrupt() function inside a node. The agent stops, waits for feedback, and then continues from the same point. This is useful when the agent needs human confirmation before taking an action.

2. CrewAI supports human-input tasks within the workflow. You can enable this by setting human_input=True in the task configuration. When the agent reaches that task, it pauses, collects feedback, and moves forward with the updated response.

3. In OpenAI’s Agents SDK, you can mark certain actions for approval using needsApproval=True. The agent pauses at those steps until the user reviews and confirms, keeping humans involved in key decisions.

4. Google’s ADK supports a human-in-the-Loop pattern. You can create a small review agent that asks for user confirmation before the main agent continues. This keeps humans in control of important decisions.

5. Observability and Monitoring

Almost every team at the conference talked about this part. No matter how advanced their setup was, observability came up again and again.

Observability shows how your agent really works, not just what it outputs. It helps you follow every step the model takes, from the first prompt to the final response.

In real-world agentic systems where many tools, memory calls, and APIs run together, observability becomes essential. It helps you spot failures early, understand the cause, and measure how each part performs.

Langfuse for Observability and Monitoring

Langfuse is an open-source observability tool built for LLM and agentic applications. It records each step in the workflow and shows a full trace of what happened. You can see how prompts evolved, which tools were called, what data was fetched, and how long each step took.

I integrated Langfuse into one of my agentic apps to see what kind of traces it captures and how deep the visibility goes.

I was able to capture all traces and observations from the app in one place. I could see the total traces, token usage, and model cost for my app at a glance.

This view gave me a full snapshot of each run - inputs, outputs, and all the metadata in between.

When I opened a single trace, I could see the full flow, how the user’s input moved through each tool and LLM call, step by step. Both preview and raw JSON views made it clear what data was being passed across the system.

It also captured detailed tool-level metrics. Langfuse showed which tools were triggered, how long they took, and how much each call cost. It’s a simple way to track efficiency and debug issues without digging through logs.

Conclusion

Taking agentic apps to production needs more than just good prompts or models.

They need safety, memory, recovery, human checks, and visibility.

• Guardrails keep your agents safe.

• Memory helps them stay consistent.

• Error handling makes them reliable.

• Human-in-the-loop brings control.

• Observability shows how everything works together.

Build, test, observe, and refine. That’s how good agents become production ready.

Hope you find this blog useful!

Happy Building!

As a result, many new agent frameworks are appearing. Some frameworks are code-based. You write code to build agents. LangGraph, CrewAI, AutoGen are some of the code-based frameworks.

Some are no-code frameworks. These let you drag and drop components to create agentic workflows. Frameworks like n8n and LangFlow work this way.

OpenAI recently released one of these no-code frameworks at their Dev Day 2025. It’s called AgentKit.

In this blog we will explore AgentKit and build a real agent with it. We will cover,

1. Agent Frameworks

2. Code vs No-Code Frameworks

3. What is Agent Kit

4. How to build an agent using AgentKit

5. Choosing the Right Agent Framework

1. Agent Frameworks

Agent frameworks help us build AI agents faster by providing useful tools and services.

Agent frameworks fall into two categories.

Code based frameworks give us packages and libraries to build agents directly in code. They offer full control and deep customization. They require more time to learn and build with, but they can handle complex logic.

No code frameworks provide visual tools where we drag and drop blocks to create the workflow. They are faster to begin with, and we can build agents in minutes. They offer less control for advanced logic, but they are great for quick automation.

2. Code vs No-Code Frameworks

Each approach has its own strengths. The table below breaks down how they compare across setup time, control level, deployment, and more.

3. What is Agent Kit

AgentKit is one of the no code frameworks. AgentKit comes with four main components.

• Agent Builder

• ChatKit

• Connector Registry

• Evals for Agents

Agent Builder:

It is a visual canvas. You can drag and drop nodes to build your agent. No coding needed for workflows. You can also export the workflow as code if you want to customize it later.

ChatKit:

It is an embeddable chat interface. Instead of building your own chat UI, you can use ChatKit to test the agentic workflow.

Connector Registry:

Connector Registry consists of tools you can connect with agents. There are some built-in tools like Google Drive, Dropbox, and SharePoint.

If a tool is not available in the registry, you can connect it through MCP (Model Context Protocol) servers.

Evals for Agents:

It is used to evaluate Agent Performance across many examples.

4. How to build an agent using AgentKit

Let us build a simple agent using AgentKit. The agent reads a GitHub repo and deploys it to Render, Vercel, or Railway based on what the user asks.

Here are the steps to build it,

Step 1: Create the Workflow in the Agent Builder

Open Agent Builder and create a new workflow. You get a blank canvas with visual nodes. Drag and drop to start shaping the decision flow.

Step 2: Add the Deployment Classifier Agent

The workflow starts with a Start node. Add an Agent node next to it and name it Deployment Classifier Agent. This agent reads the user input and classifies the deployment target. It returns a JSON with two fields, the GitHub repo and the target platform. Here is the configuration.

Below is my response schema

Here is a sample output from the Deployment Classifier Agent when the user says “deploy this github repo in render”.

You can also add guardrails in the workflow. AgentKit supports PII checks, moderation, jailbreak detection, and hallucination filtering.

Step 3: Add an If / else Node for Decision Making

Now add an If / else node after the Deployment Classifier Agent. This node checks the output from the classifier. Based on the classification value, it sends the flow to the correct deployment agent.

If the classification value from the classifier agent is,

• vercel_deployment → Connect to Vercel Deployment Agent

• render_deployment → Connect to Render Deployment Agent

• railway_deployment→ Connect to Railway Deployment Agent

• None of the above → Connect to Fallback Deployment Agent

This creates a clean decision tree where every path leads to a specific action.

Below is how the If / else node is configured and connected.

Step 4: Configure Each Deployment Agent

After the If / else node, create separate agents for every case and connect them to the correct branch.

Each deployment agent has its own MCP server connection. We also use the GitHub MCP server to read project files.

• Vercel Deployment Agent connects to the Vercel MCP server to create deployments.

• Railway Deployment Agent connects to the Railway MCP server to trigger deployments in Railway.

• Render Deployment Agent connects to the Render MCP server to deploy applications.

• Fallback Deployment Agent responds when the platform is missing or not supported and guides the user with valid options.

Here is the sample configuration for the Render Deployment Agent. Remember to add detailed instructions for every agent to perform tasks.

Once the workflow is ready, we can test it using the built in chat interface. Click Preview and send a real input to see how the agent responds.

Below you can see a test in action using ChatKit.

Step 5: Test and Deploy

Now test the workflow using a real repo.

I asked the agent to deploy a repo to Render.

The Deployment Classifier Agent identified it as a Render deployment. Then the If / Else node routed the flow to the Render Deployment Agent. The Render agent read the project files through the GitHub MCP server. It asked the required questions and deployed the app using the Render MCP server.

I also built a Code Roaster Agent to test more features. It checks a GitHub repo, finds code smells, and gives a fun roast with quick fix ideas.

Here is the workflow. The Repo Analyser Agent detects code issues and the If Else node routes it to the correct roast agent.

When I tested it with a small clear script, it actually complimented me for clean code. Looks like the clean code compliment agent has done its duty.

That is how we build agents in AgentKit. Simple and fast. Now let us compare code based and no code frameworks.

5. Choosing the Right Agent Framework

• Choose LangGraph when you want complex multi agent workflows with full control and state handling.

• Choose AutoGen when you need flexible research style agents that work together and improve with feedback.

• Choose CrewAI when you build production systems with defined roles and task delegation across teams.

• Choose AgentKit when you want fast visual workflows and easy tool integration inside your application.

• Choose n8n when business automation and many ready connectors are your main focus.

• Choose LangFlow when you want to visually prototype agent flows and test ideas quickly.

Conclusion

We started with agent frameworks and understood code based and no code approaches. We explored AgentKit and built a working agent step by step, so you now know how to use it.

Pick a real problem and try it yourself, this is the right time to ship your first agent.

Happy Building!

There’s just something about typing on a black screen. It feels more real and comfortable. Maybe that’s why dark mode is everywhere, from docs to IDEs.

Since developers spend most of their time in the terminal, it makes sense that AI agents are coming there too.

CLI Agents are growing fast. They help with coding, reviews, and all code related tasks, right inside the terminal.

In this blog, I will cover,

1. What are CLI Agents

2. Popular CLI Coding Agents

3. How CLI Coding Agents work

4. A closer look at Claude Code

5. An overall comparison of CLI agents

6. How to choose your CLI Agent

   Dev Shorts is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

1. What are CLI Agents

CLI agents are AI tools that run in the terminal. Most of them are coding agents. They understand your codebase, write code, fix bugs with natural language prompts. These tools run as shell commands.

Terminal AI agents interact with your codebase through an LLM.

2. Popular CLI Coding Agents

There are several CLI agents out there. Each one works differently.

The three leading AI providers have their own CLI agents.

• Codex CLI from OpenAI

• Claude Code from Anthropic

• Gemini CLI and Jules from Google

Alongside them, the open-source community has been very active. Developers are building their own CLI agents.

• Goose CLI

• Crush

• Qwen Code

• OpenCode

• Aider

3. How CLI Agents work

Let’s see what happens behind the scenes when you run a CLI agent in the terminal.

Step 1: User Input

You start by typing a command in your terminal. The agent reads it as plain text, for example: “add error handling to login function.”

Step 2: Context Gathering

The agent scans your workspace, reads your folders and files, checks your Git commits, and maps how everything connects. It also looks for files like AGENTS.md or README.md to understand your project.

Step 3: Prompt Construction

Next, it builds a detailed prompt for the model. The prompt includes your request, code structure, relevant files, recent changes, and coding rules. This prompt can be huge. Now LLMs can handle up to 1 million tokens.

Step 4: LLM Invocation

The agent sends this prompt to the LLM. It could be Claude, Gemini, OpenAI, or any open-source model. The model starts reasoning and streams the response back in real time.

Step 5: Reasoning and Planning

The model analyses the problem, finds the right files, and breaks the task into small steps. It decides which tools to use for reading, writing, or running commands, and then builds a clear plan before starting.

Step 6: Agentic Execution Loop

Now the agent begins the real work. It follows the plan, checks the results, and adjusts when something fails. It keeps looping through read, write, test, and fix until the code works as expected.

Step 7: Review & Commit

When done, the agent shows you the changes. You can review them line by line, accept or reject them, and even ask for tweaks. If you approve, it commits and pushes the change with a proper message.

Step 8: Feedback & Iteration

The agent learns within the session. If you prefer a different approach, it adjusts and improves. It is not training the model, but it remembers your context during the session.

Step 9: State Persistence

The agent saves your conversation, edits, and file changes. Some tools like Claude Code even offer checkpoints to revert to earlier stages or continue later from where you left off.

Now that we’ve seen how CLI agents work in general, let’s take a closer look at one of the best examples, Claude Code.

4. How Claude Code Works

Claude Code has always been my personal choice for coding. Let’s break down how Claude Code handles tasks step by step.

1. Agent Loop

Claude Code runs in a loop where it keeps calling tools until the job is done. Every task like reading, writing, or searching is done through a structured tool call.

2. Security Checks

Before running any command, Claude checks if it is safe. It uses smaller models like Haiku, to review shell commands and confirm they are not harmful. Once verified, it keeps a list of trusted commands for future use. This keeps your system protected from unwanted actions.

3. Scoped Edits

Claude works only inside the current project folder. It does not edit anything outside it, which makes the setup safe for local development.

4. Task Planning

Claude uses internal Todo tools to plan and track its work. It creates small subtasks, shows progress, and updates them in the terminal while it works.

5. Sub Agents

When the job is complex, Claude creates small helper agents to handle parts of the task. Each one works in a small context and sends results back to the main process.

6. Prompt Rules

The system prompt keeps Claude Code clear and focused. It asks the model to stay concise, follow the existing code style, avoid random comments, and use tools smartly when needed.

You can find the system prompts for many AI tools in this System Prompt GitHub Repo.

7. Context Handling

When the chat starts to reach its limit, Claude summarizes old parts automatically. It keeps only what matters so it can continue reasoning without losing track.

8. Web Tools

Claude can fetch and search the web when it needs extra information. It even uses smaller models for these tasks to save time and cost.

9. Built on the standard Anthropic API

All calls go through the same Anthropic API that any developer would use.

Some details in this section are based on a Medium article that analyzed Claude Code’s internal workflow and Anthropic’s public API behavior.

5. An Overall Comparison of CLI agents

Here’s a quick comparison of popular CLI coding agents. The table is based on insights from articles, community posts, and a few I tested locally.

6. Choose your CLI Agent

Here’s a quick guide to help you choose the right CLI agent based on your cost, privacy, and accuracy needs.

Each tool suits a different kind of developer. Choose the one that fits your workflow.

Conclusion

We explored how CLI agents work and why they’re becoming a favorite among developers. From Claude Code to Goose, each offers its own balance of accuracy, privacy, and cost.

If you spend most of your time in the terminal, these tools are worth exploring. Everyone will find an agent that fits their workflow best.

If you’re already using one, I’d love to hear how it helps you code better.

Happy coding!

It’s not just another API or plugin system. It’s a framework to build apps that run inside ChatGPT.

These apps are mini tools with their own UI, powered by an MCP server. ChatGPT can call them directly, and their responses show up right in the chat.

If the App Store is a home for mobile apps, ChatGPT is becoming a home for AI apps. Apps meet people exactly when they need them. No switching tabs, no leaving the conversation.

In this post, I’m going to build an App using Apps SDK.

We’ll cover these topics,

1. What is Apps SDK

2. Why Apps SDK

3. How to build an app for ChatGPT

4. Benefits of ChatGPT apps

The app we’ll build is a simple API Tester. Like Postman, but inside ChatGPT. Enter an endpoint, hit send, and see the result right in the chat.

1. What is Apps SDK

The Apps SDK is an Open Standard built on Model Context Protocol.

Apps SDK = MCP server + UI

It is used to build apps for ChatGPT. These apps are MCP server logic with a custom UI, all running within ChatGPT.

Like any MCP server, you define your tool and run the server. But with Apps SDK there’s one extra step. You add a UI layer that users can see and interact with directly. This UI talks to ChatGPT through a simple bridge called window.openai.

2. Why Apps SDK

ChatGPT is great at conversation. But not everything can be done inside chat.

Need to edit a design? You switch to Figma. Want to organize your notes? You open Notion.

Apps SDK brings those tools right into ChatGPT.

We know MCP connects AI systems with external tools. Apps SDK takes it further. It combines MCP with UI, so the tools you connect to ChatGPT come with their own interface.

Your app runs inside the conversation, not in a separate tab. Everything happens where the conversation is.

3. How to build an App using Apps SDK

Step 1: Identify the use case

Identify what your app should do.

I’m building an API Tester App. A simple tool to test APIs, like Postman, but inside ChatGPT.

ChatGPT can’t test APIs on its own. This app fills that gap.

Step 2: Choose an SDK

Apps SDK works with both Python and TypeScript.

The Python SDK includes FastMCP for quick setup. If you’re already working with Node or React, go with TypeScript SDK instead.

I’m using Python SDK for this API Tester App.

The official Apps SDK examples include full sample apps built in both Python and Node. You can check them out to understand the complete setup and structure

Step 3: Set up the project

Let us set up the project. The folder structure should look like this:

 API-Tester/
  ├── static/
  │   ├── api-tester.css
  │   └── api-tester.js  
  ├── pyproject.toml
  └── server.py

Add dependencies in pyproject.toml

dependencies = [
      “fastmcp>=0.1.0”,
      “httpx>=0.27.0”,
      “uvicorn>=0.30.0”,
      “starlette>=0.37.0”
  ]

Install them:

pip install -e .  

The server.py file holds your MCP server tools. The UI components (CSS and JavaScript) are in the “static” folder and get embedded inline by “server.py” when serving the widget to ChatGPT.

Understanding The App Flow

Before we dive into code, here’s how Apps SDK works. Every app needs three things

• Register your tool

• Handle tool execution

• Register the UI

Now let’s build each piece in server.py.

Step 4: Build server.py

Register your tool

from mcp.server.fastmcp import FastMCP
import mcp.types as types

mcp = FastMCP(name=”api-tester”)

@mcp._mcp_server.list_tools()
async def _list_tools():
    return [
        types.Tool(
            name=”run_api_test”,
            description=”Test an API endpoint”,
            inputSchema={...},  # Define method, url parameters
            _meta={
                “openai/outputTemplate”: “ui://widget/api-tester.html”,
                “openai/widgetAccessible”: True,
            }
        )
    ]

The _meta field tells ChatGPT which UI to render.

Handle tool execution

import httpx

async def _call_tool_request(req: types.CallToolRequest):
    method = req.params.arguments.get(”method”)
    url = req.params.arguments.get(”url”)
    
    async with httpx.AsyncClient() as client:
        response = await client.request(method, url)
    
    return types.ServerResult(
        types.CallToolResult(
            content=[types.TextContent(type=”text”, text=f”Status: {response.status_code}”)],
            structuredContent={
                “status”: response.status_code,
                “headers”: dict(response.headers),
                “body”: response.text
            }
        )
    )

# Register the handler
mcp._mcp_server.request_handlers[types.CallToolRequest] = _call_tool_request

The structuredContent is what your UI receives as window.openai.toolOutput.

Register the UI

@mcp._mcp_server.list_resources()
async def _list_resources():
    return [types.Resource(uri=”ui://widget/api-tester.html”, mimeType=”text/html+skybridge”)]

async def _handle_read_resource(req: types.ReadResourceRequest):
    if req.params.uri == “ui://widget/api-tester.html”:
        html = “”“
        <div id=”api-tester-root”></div>
        <style>/* your CSS */</style>
        <script>/* your JS */</script>
        “”“
        return types.ServerResult(
            types.ReadResourceResult(
                contents=[types.TextResourceContents(
                    uri=”ui://widget/api-tester.html”,
                    mimeType=”text/html+skybridge”,
                    text=html
                )]
            )
        )

# Register the handler
mcp._mcp_server.request_handlers[types.ReadResourceRequest] = _handle_read_resource

Build the UI

Your JavaScript receives data via window.openai.toolOutput.

// Get the data
const toolOutput = window.openai?.toolOutput;

// Display results
if (toolOutput) {
    document.getElementById(’status’).textContent = toolOutput.status;
    document.getElementById(’body’).textContent = toolOutput.body;
}

// Listen for updates
window.addEventListener(’openai:set_globals’, () => {
    const data = window.openai?.toolOutput;
    // Update UI with new data
});

Step 5: Run the App locally

app = mcp.streamable_http_app()

if __name__ == “__main__”:
    uvicorn.run(app, host=”0.0.0.0”, port=8000)

Run locally and expose with ngrok. You need HTTPS for ChatGPT to connect. Ngrok provides that temporarily. For permanent deployment, we’ll use Render, which is coming next.

python server.py
ngrok http 8000  # Get HTTPS URL 

Step 6: Deploy to Render

• Go to Render and create a new Web Service

• Connect the GitHub repository

• Set the build command: pip install -e .

• Set the start command: python server.py

• Click “Create Web Service”

Once deployed, Render gives you an HTTPS URL like below.

Now it’s time to connect the API Tester app with ChatGPT.

Step 7: Connect to ChatGPT

1. Enable Developer Mode in ChatGPT

   Settings → Apps & Connectors → Advanced Settings→ Dev mode

2. Once Dev Mode is enabled, Create a new connector with your HTTPS URL

Step 8: Test the App

Once you create the connector, you can add the app in the chat and start using it. I was able to test the API Tester app successfully.

We have just seen the code snippets. You can check the complete working code of this API Tester app in this GitHub repository.

4. Benefits of ChatGPT Apps

What makes ChatGPT apps different? Here are the key benefits.

What’s next

We discussed about Apps SDK, and we built an app for ChatGPT.

The API Tester app uses a form-based UI. You can actually build the UI you want. Check out the official examples. They include maps, carousels, and video players.

Our app doesn’t have OAuth. But you can add it. we’ve already covered OAuth implementation for MCP servers in previous posts.

OpenAI has announced they’ll start accepting app submissions later this year. They’ll also share details on how developers can monetize their apps.

The app directory is coming. So, pick a real problem, build an app that solves it, and get ready to submit.

Apps SDK is still new. The best apps are yet to be built, and your app could be one of them.

Happy building!

Some live in the terminal, some work inside your IDE. Whatever the setup, every developer is using one today.

Codex CLI, Claude Code, Gemini CLI, Cline, Cursor, Copilot. The list goes on.

If you’ve used any of these coding agents, you might know they work best when they have the right context and clear instructions. The context and guidance come from their config files.

But each coding agent has its own config file. That creates a few problems when you switch between coding agents or work in teams that use different agents.

The solution? A single file - AGENTS.md. An open standard that serves as a common config file for all coding agents.

Before we dive in, here’s what we’ll cover in this post:

1. What is AGENTS.md

2. Why AGENTS.md

3. What goes inside AGENTS.md

4. Coding Agents and their native config files

5. Bridging AGENTS.md with Coding Agents

1. What is AGENTS.md

AGENTS.md is an open format, for guiding coding agents. A single place where AI coding agents can get the context and instructions, they need for your project.

README.md is for developers, AGENTS.md is for coding agents.

Most modern agents can already detect and read AGENTS.md automatically.

It is now used by more than 40K open-source projects and supported by tools like Codex, Cursor, Gemini CLI, Factory, Amp, and many others.

2. Why AGENTS.md

The Discussion

Developers have already started asking for AGENTS.md support.

In a GitHub discussion for Claude Code, user requested for AGENTS.md support. Similarly, Cline users raised a GitHub issue asking for AGENTS.md support. Because several major tools had already adopted it.

The Reason

Since every coding agent follows its own config file, it becomes difficult when you switch tools or work in a team using different agents.

The Issue

Here is what usually happens,

1. When you switch to another coding agent, you need to create a new file for it.

2. If you clone a repo that already has a .cursor/rules file, you need to add a CLAUDE.md or another file for your own agent.

3. If you are working in a team, everyone ends up creating a different file for the same project.

4. You end up maintaining multiple files that all describe the same project.

The Solution

That is why many coding agents have started adopting AGENTS.md. Instead of many files with different names, you maintain one common file that works across tools.

3. What Goes Inside AGENTS.md

AGENTS.md isn't something completely new. It contains the same project knowledge that you'd put in any agent config file.

What we saw above is a general structure. Along with common instructions, you can also include project-specific rules and details.

Project Rules the Agent Should Know

Your Agent might understand the code, but not the business rules behind it. Add them in AGENTS.md so the agent knows how your system should behave.

## Domain Rules
- Admins can edit, not delete published content
- Orders auto-lock 2 hours after creation
- Free users get 3 exports per month
- Webhooks retry 3 times then dead letter

Architecture Decisions

Add the architecture choices you’ve already made. So, your Agent knows what to follow and doesn’t suggest things you’ve already decided.

## Architecture Decisions
- PostgreSQL: We need ACID for payments
- Redis: Session storage, not business data
- TypeScript: Catch bugs before users do
- Microservices: Deploy teams independently

Team Rules the Agent Should Follow

Every team has its own way of working. The senior developers know it, but new members and your AI won’t. Add these rules in AGENTS.md so the agent follows the same team practices.

## Team Conventions
- API errors include requestId for support
- Never show stack traces to users
- All forms validate on blur, not submit
- Cache config data, not user data

API Details the Agent Should Know

Docs are helpful, but APIs often behave differently in real use. Add these notes in AGENTS.md so your agent understands how the APIs actually behave in your project.

## API Integration Details
- Stripe: Retry anything, it's idempotent
- SendGrid: Rate limits hard, queue your emails
- S3: Takes time to be consistent, verify uploads
- Analytics: Fire and forget, don't block users

Common Issues

Every project runs into the same issues more than once. Add the ones you’ve already fixed, so you don’t waste time fixing them again.

## Common Issues
- Slow app? Check user file uploads
- Auth failing? Redis probably died
- Deploy stuck? Environment variables changed
- Memory leak? Background jobs not cleaning up

Start Small, Grow Smart

Start simple and keep improving it as your project grows. Whenever your team or AI learns something new, add it here.

Over time, AGENTS.md becomes your project’s memory. New developer joins? They understand the project right away. Switch to a different coding agent? Still gets the same context and writes the same quality code.

4. Coding Agents and their native config files

It’s important to know each coding agent’s native config file. If an agent doesn’t support AGENTS.md yet, you’ll know where to link AGENTS.md so the agent can read it.

• Claude Code uses CLAUDE.md

• Cursor uses .cursor/rules/rules.mdc

• Windsurf uses .windsurf/rules/rules.md

• GitHub Copilot reads from .github/copilot-instructions.md

• Cline uses .clinerules/rules.md

• Gemini CLI uses Gemini.md

5. Bridging AGENTS.md with Coding Agents

Some agents, such as Claude Code and Cline don’t officially support it yet. But they can still read AGENTS.md if it’s present in your project. I tested this and it works fine in most cases.

But for safer compatibility, let’s use symbolic linking. This method makes sure every agent reads from the same source without breaking its own setup.

1. Using Symbolic Linking

Make your coding agent read AGENTS.md directly by linking it like this.

# Claude Code
ln -s AGENTS.md CLAUDE.md

# Cline
ln -s AGENTS.md .clinerules/rules.md

# Cursor
ln -s AGENTS.md .cursor/rules/rules.md

# Windsurf
ln -s AGENTS.md .windsurf/rules/rules.md

# GitHub Copilot
ln -s AGENTS.md .github/copilot-instructions.md

Your tools keep working. But now they all read from the same source.

2. Using Import Inside Config Files

You can also import AGENTS.md directly inside the agent’s config file. For example, if you are using Claude Code, add this in your CLAUDE.md file.

# In ./CLAUDE.md
@AGENTS.md

This makes Claude Code read everything from AGENTS.md as its main project context. It keeps your setup simple and avoids repeating the same instructions across files.

What’s Next

Coding agents have started to follow a common standard.

Think of a future where every repo has an AGENTS.md file and every coding agent reads from the same source.

For now, we use symbolic linking or import methods to make AGENTS.md work with existing agents. It’s a simple bridge that keeps everything compatible. But this will evolve.

Soon, new agents may start looking for AGENTS.md by default.

Happy Learning!

We are in a protocol era for AI agents.

• Model Context Protocol :- MCP connects agents with tools and data.

• Agent to Agent Protocol :- A2A enables agent-to-agent communication.

• Agent Payments Protocol :- AP2 brings payments into agentic workflow.

• Agentic Commerce Protocol :- ACP is also for agent led payments.

We’ve already explored MCP and A2A in earlier posts. This post focuses on AP2.

We will cover

1. What is AP2

2. Why AP2

3. How AP2 works

4. AP2 in Action

1. What is AP2

AP2 is an open protocol. It provides a secure and verifiable way for agents to make payments on behalf of the user, with clear proof of user intent and authorization.

In simple words, this protocol, is built for the secure agent-led-payments. AP2 works through mandates. Mandates are digital contracts that are signed, secure, and cannot be altered.

In AP2, there are three types of mandates:

• Intent mandate – captures the user’s intent (what they want to buy).

• Cart mandate – captures the user-approved items, price, and shipping details.

• Payment mandate – captures the user’s approval with payment details.

AP2 fits into the current protocol stack. It works alongside A2A and MCP. So, you can add payments without rewriting your existing Tech Stack.

2. Why AP2

To understand why AP2 is needed, let’s walk through a real example.

User asks Agent- “Buy Apple AirPods Pro”.

Now let us compare how the agent handles this request without AP2 and with AP2.

AP2 addresses the three key questions in any transaction,

• Did the user authorize the purchase?

• Is the agent buying exactly what the user asked?

• Can we track who is responsible if the transaction fails?

3. How does AP2 work

As already mentioned, AP2 works based on Mandates.

1. Intent mandate– The user tells the agent what they want to buy (for example, AirPods). The agent captures this as an intent mandate.

2. Cart mandate – The agent prepares the cart with items, price, and shipping. The user reviews the cart and signs it as a cart mandate. This locks the exact items and price.

3. Payment mandate – The agent then prepares the payment mandate. This is the user’s signed approval to pay the merchant.

4. Order confirmation – The agent sends both the cart and payment mandates to the merchant. The merchant verifies them and then confirms the order.

5. Credentials – At each step, signed credentials make sure requests are authentic and verifiable.

The process above is the normal AP2 flow when the user is present. AP2 also works when the user is not present.

For example, the user may allow the agent to buy tickets when the price drops below $100, even if the user is not there at that moment.

In that case, the agent gets a detailed Intent Mandate with specific conditions, signed by the user. The agent then creates the Cart Mandate when those conditions are met and completes the order transaction.

4. AP2 in Action

Google has open-sourced sample code and scenarios to help developers try AP2 locally.

The AP2 repo includes:

• Python and Android samples showing shopping and checkout flows.

• An Agent Development Kit (ADK) setup to run the samples.

• Ready-to-use scripts to start roles like merchant, payment processor, and shopping agents.

These samples use Gemini 2.5 Flash in the demos, but you can swap in any model.

Now, let’s get it running.

Step 1: Clone the repo

git clone https://github.com/google-agentic-commerce/AP2.git

Step 2: Install dependencies

AP2 uses uv for Python packages.

cd AP2/samples/python
uv sync

Step 3: Set your API key

You need a Google AI Studio API key.

Linux / Mac / Git Bash

export GOOGLE_API_KEY=”your_api_key”

Windows CMD

set GOOGLE_API_KEY=your_api_key

Step 4: Run the agents

In different terminals, start each role.

cd AP2/samples/python

uv run --package ap2-samples python -m roles.merchant_agent
uv run --package ap2-samples python -m roles.credentials_provider_agent
uv run --package ap2-samples python -m roles.merchant_payment_processor_agent
uv run --package ap2-samples adk web src/roles

Step 5: Try it in the browser

Open http://localhost:8000/dev-ui.

Pick the shopping agent and give it a command, for example:

“Buy Apple AirPods Pro under $200.”

The agent:

• Captures user intent.

• Builds a cart mandate.

• Requests payment mandate.

• Sends signed proofs to the merchant.

• Merchant verifies and confirms the order.

Step 6: Hands-On Run

In my test run, I ran the flow up to the cart mandate step. At that point, the agent asked whether to use a digital wallet.

If you want to try the full checkout, you can continue by connecting your own digital wallet and check how it works.

Looking Ahead

AP2 is still new, but it solves a real gap for agent-driven commerce. It makes payments safe, verifiable, and accountable.

For developers, this is the right time to experiment with AP2. Try the sample flows and see how it fits into your stack.

You might also want to check out another initiative called the Agentic Commerce Protocol (ACP), released more recently. It is also built for agent led payments. You can explore ACP GitHub repo and Stripe’s blog post for early details.

I will cover more about this ACP protocol in a future post. For now, AP2 is a great starting point to get hands on with agentic commerce.

As more merchants, wallets, and banks adopt it, we can expect more agent-led transactions.

More AI posts are coming. Let us keep exploring!

In this blog, I’ve collected must-know GitHub repos grouped by category. These include everything from LLM fundamentals to RAG, MCP, Agents, Agentic frameworks, and coding agents that can sharpen your AI development journey. These repos are building blocks for any AI engineer looking to learn and build.

1. LLM Repos

• LLMs-from-scratch: This repo shows how to build and train GPT-style models. It explains the process step by step with clear code.

• Hands-On-Large-Language-Models: This repo has code for practical LLM tasks. It covers text classification, search, clustering, embeddings, and fine-tuning.

• llm-course: This repo has an LLM course. It includes roadmaps and Colab notebooks covering fundamentals, fine-tuning, quantization, and deployment.

• awesome-generative-ai-guide: This repo serves as a GenAI hub. It provides updates on research, interview prep, course material, and app-building guides.

• Awesome-LLM: This repo collects papers and resources about LLMs. It also includes frameworks, tools, and benchmarks.

• nanoGPT: This repo is by Andrej Karpathy. It gives a simple way to train and fine-tune medium-sized GPTs with clean code.

• LLM-engineer-handbook: This repo has resources for AI engineers. It covers training, serving, fine-tuning, and running LLMs in production.

• learn-ai-engineering: This repo is a resource for beginners. It teaches AI, LLMs, agents, prompts, and fine-tuning from scratch.

2. MCP Repos

• Model Context Protocol: This repo has the base MCP implementation from Anthropic. It is the open standard to connect AI applications with external tools and data.

• Awesome MCP Servers: This repo has a curated list of MCP servers. These servers help you connect MCP clients with external tools.

• Awesome MCP Clients: This repo lists different MCP clients. You can explore them and see how they work with servers.

• mcp-use: This repo provides a Python library called mcp-use. It connects any LLM with any MCP server.

• MCP Containers: This repo gives you containerized MCP servers. They are simple to run and deploy.

• mcp-ui: This repo has UI components for MCP. Servers can serve them, and clients can render them for interactive use.

• MCPHost: This repo provides a CLI tool called MCPHost. It lets you run MCP servers and connect models like Claude, OpenAI, Gemini, and Ollama with external tools.

3. Agents Repos

• AI Agents for Beginners: This repo has lessons with code examples. It helps you get started with building AI agents.

• GenAI Agents: This repo provides implementations of AI agents. It covers basics, LangGraph workflows, multi-agent systems, and advanced applications.

• Awesome AI Agents: This repo offers a curated list of AI agents. It includes projects across different categories and industries.

• Prompt Engineering Guide: This repo has guides, papers, and notebooks. It focuses on prompt engineering techniques with large language models.

• System Prompts and Models of AI Tools: This repo exposes system prompts and tools used by popular platforms. It covers Cursor, Claude Code, Lovable, and others.

• 500 AI Agents Projects: This repo contains over 500 AI agent projects. It has examples from healthcare, finance, education, retail, and more.

• Agents Towards Production: This repo has step-by-step tutorials. It shows how to build GenAI agents that are ready for production.

• Awesome AI Apps: This repo includes tutorials and examples. It shows how to build LLM-powered apps from chatbots to advanced agents.

• AI Engineer Toolkit: This repo gives you projects and resources. It helps build production-grade AI apps with popular frameworks and tools.

4. Coding Agents Repos

• Claude Code: This is Anthropic’s official repo. It is a popular coding agent for terminal-based AI assistance.

• OpenAI Codex: This repo is OpenAI’s coding agent. It runs locally in your terminal and works as an alternative to cloud-based coding assistants.

• Gemini CLI: This repo is Google’s command-line tool. It brings Gemini AI into your terminal for code analysis and automation.

• OpenManus: This is an open-source coding agent. Developers use it when they want full control without vendor lock-in.

• Goose: This repo is Block’s coding agent. It is capable of automating complex development tasks from start to finish.

• opencode: An AI coding agent built for the terminal. It is open source and works with any provider or model via a simple client interface.

• Crush: This repo is Charm’s coding agent. Developers like it for its clean interface and smooth integration with local tools.

• Cline: This is a VS Code extension. It works as an autonomous coding agent that creates files, runs commands, and handles complex workflows.

• Forge: This repo is an AI pair programming tool. It supports more than 300 models and allows multi-provider flexibility.

• Open Deep Research: This repo is from LangChain. It is an open-source research agent. It works across many model providers, search tools, and MCP servers.

• Void: It is an open-source coding editor. It is a free alternative to Cursor with checkpoint visualization.

• Awesome Cursor Rules: This repo is a collection of config files. Cursor users rely on them to customize their editor experience.

• Awesome Claude Code: It is community curated. It has Claude Code workflows and commands that improve productivity.

5. RAG Repos

• RAG Techniques: It covers different advanced methods that boost retrieval and generation.

• RAG From Scratch: This repo shows how to build RAG step by step with clear notebooks.

• RAG Anything: It is an All-in-One RAG Framework. You get a flexible framework packed with tools.

• RAG Time: Microsoft designed this as a 5-week Learning Journey to Mastering RAG.

• FlashRAG: The toolkit includes datasets, algorithms, and a GUI for fast RAG research.

6. LLM Framework Repos

• LangChain: A popular framework repo for building with LLMs. It supports agents, RAG, apps, memory, and many integrations.

• LlamaIndex: Another popular framework repo for working with LLMs. It helps build agents, RAG systems, and LLM applications.

• Haystack: It is an AI orchestration framework to build customizable, production-ready LLM applications.

• Ollama: This is a framework to run open-source LLMs locally on your machine.

• llama.cpp: This repo enables running LLMs locally using C and C++. It makes inference faster and lighter, even on modest hardware.

• Unsloth: An open-source framework for LLM fine-tuning and reinforcement learning. It makes training faster and more efficient.

• Guidance: A guidance language for controlling large language models.

• DSPy: An open-source Python framework. It helps optimize prompts and modules automatically.

• Transformers: It is the core library for pretrained models with APIs for training, fine tuning, and deployment.

7. Agentic Framework Repos

• LangGraph: An orchestration framework for building, managing, and deploying long-running, stateful agents.

• OpenAI Agent SDK: A framework from OpenAI. It supports building multi-agent workflows.

• AutoGen: This is Microsoft’s agent framework. It helps create multi-agent AI applications.

• SmolAgents: A lightweight framework from Hugging Face. It lets you build and run agents with minimal setup.

• CrewAI: A framework for orchestrating AI agents. It is fast and flexible for building multi-agent workflows.

Conclusion

This blog highlights key GitHub repos every AI engineer should know. The list includes LLMs, RAG, MCP, agents, frameworks, and coding agents.

Each repo offers a chance to learn or build something useful. Some help you start small, while others let you scale into real apps.

Bookmark this list and refer back to it as you progress in your AI journey.

Happy Learning!

In my earlier posts, I covered MCP topics from the basics to OAuth. Here are some of those articles.

• How to build your own MCP Server?

• How to host your MCP Server?

• How to implement OAuth for MCP Server

• Ten Must-Know MCP Servers

• How to build an MCP Client

This time we will see the complete workflow. We will build the MCP Server, dockerize and deploy it, and finally connect with LLMs and Agents.

This blog covers,

1. Build MCP Server

2. Containerize using Docker and Podman

3. Deploy with Render and Railway

4. Docker Deployment Vs Direct Deployment

5. Test with MCP Inspector

6. Connect MCP Server with LLMs, Agents

1. Build MCP Server

We will start by building a simple MCP Server with the FastMCP framework. An MCP Server has three core features. They are,

1. Tools

2. Prompts

3. Resources

"Tools" are functions that the LLM can call to perform an action. "Prompts" and "Resources" serve different purposes. In our example we will focus only on tools.

Our server has a single tool called "web_extraction". It takes a URL as input and returns the page content. Of course, an MCP server can have multiple tools, each designed for different tasks.

Here’s the code for the Web Extraction MCP Server.

from fastmcp import fastmcp
import requests
from bs4 import BeautifulSoup

mcp = fastmcp("Web Extraction MCP Server")

@mcp.tool
def web_extraction(url: str) -> str:
    response = requests.get(url)
    soup = BeautifulSoup(response.text, "html.parser")
    return soup.get_text(separator='\n')

if __name__ == "__main__":
    mcp.run(transport="http", host="0.0.0.0", port="8000")

The full source code for the Web Extraction MCP server, including the pyproject.toml file, is available in this GitHub repo.

You don’t always need to build an MCP server from scratch. Many servers are already available in the MCP registry for common tools and use cases. If you find one that fits your needs, you can simply change the server code from STDIO to a streamable HTTP server by using mcp.run(transport="http"). Then containerize it and deploy for real time use.

2. Containerize using Docker and Podman

Now let us containerize our MCP server. We will cover both Docker and Podman approaches for containerization.

Containerization bundles the app with everything it needs to run. This fixes the "it works on my machine" problem. With this approach, MCP server will run the same across local development, staging, and production environments.

Using Docker

Step 1. Create the Dockerfile

First, we need to create a Dockerfile that defines our container environment:

FROM python:3.11-slim

# Set working directory
WORKDIR /app

# Install system dependencies
RUN apt-get update && apt-get install -y \
    gcc \
    && rm -rf /var/lib/apt/lists/*

# Copy requirements files
COPY pyproject.toml ./

# Install Python dependencies
RUN pip install --no-cache-dir -e .

# Copy application code
COPY server.py ./

# Expose the port the app runs on
EXPOSE 8000

# Create a non-root user for security
RUN useradd --create-home --shell /bin/bash app \
    && chown -R app:app /app
USER app

# Run the application
CMD ["python", "server.py"]

Step 2. Build the Docker image from the Dockerfile

docker build -t web-extractor-mcp-server .

Step 3. Tag the image for the registry

docker tag web-extractor-mcp-server your-dockerhub-username/web-extractor-mcp-server:latest

Step 4. Authenticate with Docker Hub

docker login

Step 5. Push the image to Docker Hub

docker push your-dockerhub-username/web-extractor-mcp-server:latest

Using Podman

We can also containerize using Podman. It is a container engine that runs without a background daemon. It supports rootless containers, offering better security by default.

Step 1. Build the image

On some systems, Podman requires sudo unless your user is set up for rootless containers. In my case, the working command was.

sudo podman build -t web-extraction-mcp .

Step 2. Verify image was created

podman images

Step 3. Tag for registry

Podman supports multiple registries including Docker Hub and GitHub Container Registry.

sudo podman tag web-extraction-mcp:latest your-dockerhub-username/web-extraction-mcp:latest

Step 4. Authenticate with the registry

podman login docker.io

Step 5. Push the image to the registry

 sudo podman push your-dockerhub-username/web-extraction-mcp:latest

With Docker images ready, we can now deploy them to various platforms.

3. Deploy with Render

Let's start with Render first.

Connect the Docker image and deploy as a web service through Render's dashboard. The platform will pull the image and handle the deployment process.

Deploy with Railway

Railway works much like Render. Connect the Docker image and Railway will handle the deployment process automatically.

Now that our MCP server is deployed, before connecting it with LLMs and Agents, let’s look at why Docker deployment is better than direct deployment

4. Direct Deployment Vs Docker Deployment

Direct deployment can fail when the local and server environments don’t match. Docker solves this by packaging everything, so the MCP server runs the same everywhere.

Here’s a quick comparison between Direct deployment and Docker deployment.

5. Test with MCP Inspector

MCP Inspector is the standard tool for testing and debugging MCP servers. It provides a user interface to interact with the server's tools and verify functionality.

1. Run npx @modelcontextprotocol/inspector

2. Open MCP Inspector.

3. Enter MCP Server deployment URL with /mcp at the end.

4. Click "Connect" to establish the connection.

5. Once connected, we can see the list of tools our MCP Server provides.

In our case, after we connect with our deployment url, our web_extraction tool shows up in the list. This proves our deployed MCP server is working properly.

Share

6. Connect MCP Server with LLMs, Agents

MCP Servers become really useful when you connect them with LLM-powered apps and agents. In this section, we will see how to connect them with LLMs Agents, and code editors.

6.1 Connect MCP Server with Anthropic API

To connect with an MCP server you normally need an MCP client, but some providers now let their LLMs talk to MCP servers directly through their APIs.

Here’s an example of connecting an MCP server with the Anthropic API. You can see Anthropic’s docs for more details

import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1000,
    messages=[{
        "role": "user",
        "content": "What tools do you have available?"
    }],
    mcp_servers=[{
        "type": "url",
        "url": "https://mcp.example.com/sse",
        "name": "example-mcp",
        "authorization_token": "YOUR_TOKEN"
    }],
    betas=["mcp-client-2025-04-04"]
)

6.2 Connect MCP Server with OpenAI Agent

OpenAI’s Agent supports MCP servers. The table below shows the different MCP integration options supported by the OpenAI Agent Python SDK.

You can read more about these options in the OpenAI MCP docs.

For example, here’s how an OpenAI Agent connects with a Streamable HTTP MCP server.

import asyncio
import os

from agents import Agent, Runner
from agents.mcp import MCPServerStreamableHttp
from agents.model_settings import ModelSettings

async def main() -> None:
    token = os.environ["MCP_SERVER_TOKEN"]
    async with MCPServerStreamableHttp(
        name="Streamable HTTP Python Server",
        params={
            "url": "http://localhost:8000/mcp", # URL of the MCP server
            "headers": {"Authorization": f"Bearer {token}"},
            "timeout": 10,
        },
        cache_tools_list=True,
        max_retry_attempts=3,
    ) as server:
        agent = Agent(
            name="Assistant",
            instructions="Use the MCP tools to answer the questions.",
            mcp_servers=[server],
            model_settings=ModelSettings(tool_choice="required"),
        )

        result = await Runner.run(agent, "Add 7 and 22.")
        print(result.final_output)

asyncio.run(main())
   

6.3 Connect MCP Server with Claude Code

We can also add MCP Server with Claude Code.

claude mcp add --transport http web-extractor-mcp https://web-extractor-mcp-server-1.onrender.com 

Running this command connects the MCP server to Claude Code.

6.4 Connect MCP Server with Code Editors

1. Cursor Code Editor provides three ways to connect with MCP servers, so your tools can be accessed directly while coding.

   • Cursor-MCP one-click installation

   • Using mcp.json

   • Using the Extension API

2. VS Code also provides multiple options to add MCP servers, including workspace-level, user-level, and dev container configurations:

   • VS Code – How to add an MCP server

3. Windsurf supports MCP through Cascade, so you can plug in your servers and use their tools directly in the editor.

4. Zed also has MCP integration, letting you add servers in its config and access MCP tools while coding.

5. LangChain provides MCP adapters, allowing you to use MCP servers inside your workflows and agents.

6. LlamaIndex supports MCP, so you can use MCP servers as tools in your pipelines and agents.

Some websites like MCP Server Org provide one-click MCP Server installation options for VS Code and Cursor. It makes setup faster but ensure the legitimacy of the site before installing. Only add MCP servers from trusted publishers and review their configuration carefully.

6.5. Connect Any LLM with Any MCP

mcp-use is an open-source toolkit that connects any LLM to any MCP server, so you can build agents with tool access without relying on closed clients.

MCPHost is a CLI host application that connects LLMs with MCP servers. It supports multiple providers like Claude, OpenAI, Gemini, and Ollama.

6.6 Connect MCP Server with ChatGPT

OpenAI recently added support for MCP Server in ChatGPT. This means you can integrate your own custom MCP servers directly into ChatGPT and use their tools inside conversations.

To set it up, enable Developer Mode under Advanced Settings. Then create a Connector. From there, you can fill in the details of your MCP server (name, description, and URL).

6.7 Connect MCP Server with Claude Desktop

We can connect MCP Server with Claude Desktop in two ways:

Through the UI (paid users only)

• Open Claude Desktop Settings → Connectors → Add Custom Connector.

• Enter MCP server’s deployment URL and save the configuration.

Through claude_desktop_config.json (all users)

• Open the configuration file: claude_desktop_config.json.

• Add a new entry for MCP server with the deployment URL.

Let us now try connecting our Web Extraction MCP Server with Claude Desktop.

Once connected, our web extraction tool is available directly within Claude Desktop. We can now ask Claude to extract content from any webpage, and it will use MCP server’s tool to perform the task.

Conclusion:

In this guide, we explored the full journey of MCP servers. We built a simple MCP server, then containerized, deployed, and connected it with LLMs, agents, and editors.

MCP opens the door to building powerful agents with tool access without the friction of custom integrations.

Give MCP servers a try, and happy learning!

I have written about agents before. Here are my blogs on them.

How to build a Full Stack Application using AI Agents

What are AI Agents and Must-Try Agents for Every Developer

Recently, OpenAI has shipped ChatGPT Agent. This can now do your work using its own computer. It can handle complex tasks from start to finish.

In this blog, we will cover ChatGPT Agent from features to architecture. Here is the outline.

1. Browser Agent - ChatGPT Agent runs on its own virtual desktop.

2. Connectors - ChatGPT Agent uses Connectors to connect with external tools.

3. Scheduling - ChatGPT Agent has Scheduling option to schedule the task.

4. Website Permissions

   1. How to allow ChatGPT Agent to access your website.

   2. How to block the OpenAI crawlers accessing your site.

5. Architecture - ChatGPT Agent reverse engineered - live streaming & control

   Dev Shorts is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

1. Browser Agent

Click Agent mode to activate ChatGPT Agent.

The ChatGPT Agent sets up its own virtual desktop and performs tasks. It can book tickets, create files, order items, or carry out any task based on the prompt.

It combines Operator mode and Deep Research. Operator could act. Deep Research could analyze. Now both run together in one unified flow.

It uses a browser agent that can browse and interact with websites. For sensitive actions like logins and credentials, it gives control back to user.

I tried ChatGPT Agent for a grocery order. The initial order was successful. On the second try it struggled because the item was out of stock, but overall, the experience was good.

The video below shows how it gives control back to users for sensitive steps like login.

The only drawback I noticed was that for a simple order it took quite a bit of time. If I had ordered, I would have done it faster. But I understand this is just the beginning, and the process will only get better over time.

2. Connectors

ChatGPT Agent can connect to external tools through connectors. Connectors have been in regular chat for a while. Now the Agent can use them too. And Web browsing is enabled by default for Agent.

You can find more connectors in Settings → Connectors.

When you connect a tool, you allow the Agent to read data and take actions in that tool. You still approve sensitive steps while it works.

You can add custom connectors too. They’re available for ChatGPT Pro, Team, and Enterprise workspaces. To create a connector, build an MCP server that links external tools or data sources, then deploy it, and connect it with ChatGPT.

If you want to learn more about MCP, check out my blogs on building MCP servers, deploying them, and adding OAuth support.

• How to build your own MCP Server?

• How to host your MCP Server?

• How to add OAuth in MCP Server?

3. Scheduling

You can now schedule ChatGPT Agent tasks. For Example: Set up a monthly grocery order. Tell the Agent what to buy and set it to run every month. You can include instructions in the schedule. You can use the scheduling option for any kind of recurring tasks.

Manage the scheduled tasks under settings→ schedules.

4. Website controls

We all know ChatGPT access websites. OpenAI uses three types of crawlers for this. Each crawler is for different purposes. Website owners need to understand them. You can control which ones access your site.

How to block the ChatGPT bots

We listed the OpenAI bots above. To block them from your site, place the following entries in your robots.txt.

User-agent: OAI-SearchBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: GPTBot
Disallow: /

How to Allow ChatGPT Agent Access to Your Website

The ChatGPT Agent works like a bot that can perform real tasks on websites, from browsing pages to completing actions like shopping. Some site owners may want to allow the Agent to visit their site, since it handles genuine tasks like shopping or bookings.

The challenge is that fake bots could try to pretend to be ChatGPT Agent. To prevent this, you need a way to verify that a request is truly coming from the Agent.

OpenAI solves this by adding cryptographic signatures to every request. These signatures prove the request is genuine. By checking them, you can allow the real Agent while blocking impostors.

For detailed steps, see OpenAI’s guide on ChatGPT Agent allowlisting.

5. Reverse Engineering ChatGPT Agent

After looking at the features, I wanted to see how the Browser Agent actually works under the hood. Since its proprietary, the full architecture isn’t public. But I came across an article that reverse-engineered ChatGPT Agent and described a likely design.

It explains how the agent launches a browser inside a virtual desktop, streams it live, and even hands control back to you when needed. When you move the cursor, those actions are applied directly to its virtual desktop. With the right workflow and infrastructure, this setup becomes possible.

A prototype built with this approach behaved much like ChatGPT Agent. You can see this prototype in action in the video below.

Source:- POC on ChatGPT Agent

To make it clearer, here’s a diagram showing steps of live streaming and user control.

Let us see the flow in detail now.

1. User Types Prompt in Chat Interface

The user enters a prompt in the chat. The system captures it and forwards it to the backend, where it’s added to a queue for execution.

2. Server Receives and Parses Command

The backend receives the request, analyzes the instruction, identifies the intended action, and extracts the key parameters needed to perform it.

3. Browser Action Execution

The backend sends the instruction to the browser session. The browser opens the target site, navigates to the right section, fills in fields, and performs the required clicks or actions.

4. Screenshot Capture and Processing

The system continuously captures snapshots of the browser at short intervals. Each snapshot is resized, compressed, and encoded so it can be streamed efficiently without losing clarity.

5. Real-Time Streaming and Display

The server streams the processed frames back to the client in real time. So, the user sees a smooth live view of the agent’s actions as they happen.

6. User Can Take Manual Control

When the user clicks on the live stream, the system captures the click coordinates and sends them to the backend. The virtual browser then performs the same action at that location.

7. State Synchronization and Maintains Session

The browser, backend, and client remain in sync so that actions and visuals stay aligned. If the connection drops, the session can recover without losing progress.

8. Continuous Feedback Loop

Every action is reflected in the next frame, creating a constant loop of feedback. The user gains confidence by seeing the process live and can choose to stop, take over, or let the Agent continue.

This is a likely architecture based on reverse engineering. It may not match the exact internal design of ChatGPT Agent, but a prototype built with this approach was tested and worked in a similar way.

Conclusion

Hope you now got a clear idea about ChatGPT Agent, its core features, and the architecture behind how it works.

For additional details about ChatGPT Agent, including how reinforcement learning guides tool selection, benchmark results, and safeguards against risks like prompt injection, check this video from OpenAI.

The agentic space is evolving fast, and we will see even more powerful agents as this technology matures.

Happy learning!

I have written articles on MCP covering topics like,

• How to build your own MCP Server?

• How to host your MCP Server?

• Ten Must-Know MCP Servers

• How to build an MCP Client

This is my fifth post in this series. Since I haven’t implemented OAuth with MCP servers before, I decided to give it a try and document the process in this blog.

In this blog, I’ll cover:

1. Quick MCP intro

2. MCP Transport Types

3. Understanding OAuth

4. OAuth Authorization flow for MCP Servers

5. Build and Deploy OAuth-protected MCP Server

6. Test OAuth MCP Server

1. Quick MCP intro

For those new to MCP, it’s a Model Context Protocol that connects LLMs with external data. LLMs exist primarily on the client side. MCP clients talk to MCP servers. The server connects to external systems, fetches data, and sends it to the LLM running in the client.

The Model Context Protocol lets you build MCP servers that expose data and functionality to LLMs.

MCP servers have:

• Resources (@mcp.resource) - Expose data to LLMs (like reading files or databases)

• Tools (@mcp.tool) - Provide functionality to LLMs (like sending emails or running code)

• Prompts (@mcp.prompt) - Define reusable templates for LLM interactions

2. MCP Transport Types

MCP supports different transport types for connecting clients and servers.

• STDIO Transport (Local)

• Streamable HTTP Transport (Remote)

• Custom Transport

STDIO Transport: (Local)

If you're planning to build a local MCP server that runs on the same machine as your client, use STDIO transport. The client will automatically launch your server as a subprocess when it starts up.

if __name__ == "__main__":
    mcp.run()    # Uses STDIO transport by default

Streamable HTTP Transport: (Remote)

If you're planning to build a remote MCP server that clients can access from different machines, use Streamable HTTP transport. Your server will run as a standalone service that clients can connect to over the network.

if __name__ == "__main__":
   #To use HTTP, specify it in the run() method along with networking options
    mcp.run(transport="http", host="127.0.0.1", port=8000)  

This Streamable HTTP Transport replaced the older HTTP+SSE transport method.

Custom Transport

If you need specialized communication between your client and server that doesn't fit STDIO or HTTP patterns, build a custom transport. You define exactly how your client and server will communicate based on your specific requirements.

Here are some key differences between these transports.

From the above table, we clearly know that OAuth is for remote servers. For Local Servers, credentials can be fetched from environment variables.

3. Understanding OAuth

OAuth is an Open Authorization that lets a client access a server’s resources without the user having to share their credentials.

If no credentials are shared, how does OAuth authorize the client to access the server?

They use access tokens. These tokens are used to authorize the client to access the server.

In the MCP setup, there is a MCP client and a MCP server. When the server has OAuth enabled, it requires every incoming request from the client to include a valid access token. The client attaches this token to each request, and the server verifies it before processing. If the token is valid, the request is allowed, if not, the server blocks it. This ensures that only authorized clients can access the server.

But now a big question comes up.

How does the client get this token?

Here’s how the client obtains an access token in the MCP setup.

The client sends a first request to the MCP Server without any Token. The MCP server responds with a 401 error along with details about which Authorization Server to use and how to request a token. Using this information, the client contacts the Authorization Server, obtains a token, and then uses it to access the MCP Server.

Access tokens are not only used to authorize clients. They also specify what level of access the client has, such as read or write permissions.

I hope now you have a clear idea of what OAuth is and how it controls access between the client and the server.

4. OAuth Authorization flow for MCP Servers

There are four common types of OAuth flows.

In this blog, we are going to see the Authorization Code Flow With PKCE, as this setup supports dynamic clients where any genuine client can authenticate and use the MCP Server.

How Authorization Code Flow with PKCE Works

1. The MCP Client starts by sending a request to the MCP Server without a token.

2. The MCP Server responds with a 401 Unauthorized and provides authorization server details.

3. The Client extracts the metadata URL, fetches the metadata, and learns about the authorization and token endpoints, scopes, and supported grant types.

4. The Client may register itself dynamically with the Authorization Server to obtain client credentials.

5. The Client generates PKCE parameters (code_challenge, code_verifier) and opens the browser to the Authorization Server’s login page, passing client_id, resource details, and code_challenge.

6. The User logs in and approves the access request.

7. The Authorization Server redirects back to the Client with an authorization code.

8. The Client sends the authorization code along with the code_verifier to the Authorization Server’s token endpoint.

9. If valid, the Authorization Server returns an access token.

10. The Client retries the MCP request, now including the access token.

11. The MCP Server validates the token and grants access.

12. From this point, the Client continues communicating with the MCP Server using the access token until it expires.

5. Build and Deploy OAuth-protected MCP Server

Now we are going to build MCP Server with OAuth and deploy in Render.

• Server: Streamable HTTP MCP Server

• Framework: FastMCP

• Auth Provider: Auth0

• Hosting: Render

Here’s the simple MCP Server Code with OAuth implemented.

from fastmcp import FastMCP
#from fastmcp.server.auth import RemoteAuthProvider
from fastmcp.server.auth.providers.jwt import JWTVerifier
from pydantic import AnyHttpUrl
import os
import sys
from datetime import datetime

# Read from environment
AUTH0_DOMAIN = os.getenv("AUTH0_DOMAIN", "your-tenant.us.auth0.com")
AUTH0_AUDIENCE = os.getenv("AUTH0_AUDIENCE", "https://your-api-identifier")
RESOURCE_SERVER_URL = os.getenv("RESOURCE_SERVER_URL", "https://your-domain.example.com/mcp") # your mcp server deployment url

# JWT verification setup
token_verifier = JWTVerifier(
    jwks_uri=f"https://{AUTH0_DOMAIN}/.well-known/jwks.json",
    issuer=f"https://{AUTH0_DOMAIN}/", # note the trailing slash
    audience=AUTH0_AUDIENCE            # must match your API identifier exactly
)

# Remote OAuth provider for MCP
auth = RemoteAuthProvider(
    token_verifier=token_verifier,
    authorization_servers=[AnyHttpUrl(f"https://{AUTH0_DOMAIN}/")],
    resource_server_url=RESOURCE_SERVER_URL      # usually your /mcp endpoint
)
mcp = FastMCP(name="Protected MCP Server", auth=auth)


@mcp.tool  
def test_str(name: str) -> str:    
    return f"Hello, {name}!"


if __name__ == "__main__":
    port = int(os.environ.get("PORT", 8000))

    # Start an HTTP server on port 8000
    mcp.run(transport="http", host="0.0.0.0", port=8000)

Auth0 Configurations

Quick setup guide for Auth0 configuration required for OAuth-protected MCP server.

Step 1. Create Application

• In the Auth0 Dashboard, under Applications, create an application.

• Link it to default API - Auth0 Management API or your own API if you plan to create as mentioned in step 2.

• Grant the scopes: create:clients, read:clients, update:clients.

Step 2: Create API (Audience)

• This step is needed if you want your own API instead of the default Auth0 Management API.

• Under Applications → APIs, create a new API (e.g., MCP Server API).

• Use a unique identifier (e.g. https://mcp-content-api ) with signing algorithm RS256.

• Define scopes such as mcp:read, mcp:write

Step 3: Enable Dynamic Client Registration

• Go to Auth0 Dashboard

• Go to Settings → Advanced tab

• Enable "OIDC Dynamic Application Registration"

Step 4: Make the API Identifier as Default Audience

• Go to Auth0 Dashboard

• Go to Settings → General Tab

• Make your Identifier as Default Audience

Remember to do step 3, and 4. Else you will not be able to connect your MCP Server from client even after authorization.

With Auth0 configured, we can now deploy the MCP Server on Render.

Deploy Remote MCP Server

• In Render Dashboard, Create Web Service from Git repo.

• Set the Build Command: pip install -r requirements.txt

• Set the Start Command: python server.py

  

• Add Environment Variables

  

• Click Deploy - MCP Server will be live at the Render URL

  

6. Test OAuth MCP Server

I connected this remote OAuth MCP Server through MCP Inspector.

When you click Connect, the authorization flow begins.

After you approve the request, MCP Inspector establishes the connection and loads the tools from the server.

Now test the tool from our MCP server: Enter a name, and the server responds with Hello {name}.

This is how it works.

Enable Google OAuth in Auth0

To allow users to sign in with Google, enable the Google OAuth in Auth0.

• In the Auth0 Dashboard, go to Authentication → Social → Google OAuth.

• Under Applications, turn on the toggle for your application.

• Save the changes.

Once enabled, users can sign in to the MCP server using their Google account.

Conclusion

We walked through how to add OAuth to an MCP server step by step.

I couldn’t find a clear guide on setting up OAuth for an MCP server, so I put this together to show a simple, working flow from start to finish. The code and settings here are tested and working, and this MCP Server can work with other MCP clients too.

You can use any OAuth provider. Just wire it to your MCP server and see how it works for you.

Happy learning!

Can we really use AI at every stage of product development, from ideation to deployment, and still ship a full-stack app that actually works?

To figure this out in detail, I decided to take a hands-on approach. I built a complete full stack app using AI tools. This blog walks through how I built it from end to end and highlights the tools I used at each stage.

Here are the stages I followed and the tools I used at each step.

1. Product ideation - with O3

2. Requirements planning - with Traycer AI & Task Master AI

3. Code implementation - with Claude Code

4. Code review - with CodeRabbit

5. Testing - using Claude Code and MCP Servers

6. Deployment - using Claude Code and MCP Servers

If you’d like to read more posts on building with AI, you can subscribe below.

Product Development Stages

When building this full stack app, I divided the product development process into clear stages. Everything started with the idea and moved step by step until deployment. Here are the stages I followed.

The next diagram shows which AI Tool I used, from product ideation to deployment.

1. The Product Ideation:

For product ideation, I asked o3 to suggest some ideas. o3 is a reasoning model from OpenAI. I gave a short prompt asking for product ideas and it returned a list of ideas. I picked the one that felt interesting to me. It was called Virtual Try on App.

Here’s what the app will do. Users upload their photo and a dress image. The app shows how the outfit looks on their body. It helps them decide before buying.

I liked this idea because it’s visual and interactive. It needed a good frontend to handle the image uploads and solid backend to process the images.

This app was a good use case for me to test how well AI agents can build a real full stack application.

2. Preparing PRD and Plan

The next step was preparing the Product Requirements Document (PRD) and Technical Plan Document.

Think of the PRD as the blueprint for the product. It defines what you are building and why. It outlines the core features, constraints, and assumptions. Basically, it serves as a high-level document that explains the product.

I gave the product description to O3 and asked it to prepare PRD.md.

Plan with Traycer

Once PRD was clear, I gave it to Traycer AI, and asked it to generate technical_plan.md

Plan with Traycer, and Tasks with TaskMaster

After creating the technical plan, there's another option I explored: TaskMaster AI. I tested giving that plan to TaskMaster, and it generated a detailed task breakdown. While I didn't follow this task-by-task approach for this blog, it's worth noting as an alternative workflow. I'll cover TaskMaster in a separate post.

Here is a glimpse of the tasks generated by TaskMaster AI. Each task had an ID, title, description, priority, test strategy, and step-by-step instructions.

These tasks could be completed by the TaskMaster Agent itself or passed to Claude Code or any terminal agent to build the codebase task by task.

For this experiment, I used the direct Plan with Traycer approach.

I shared a PRD with Traycer, and it gave me a detailed technical_plan.md covering the system overview, architecture, and approach.

Here were the kinds of details Traycer included in the Technical Plan,

• Tech stack and framework selection

• End-to-end data flow

• Service communication diagrams

• Environment setup

• Testing strategy

• Deployment and monitoring plan

By the end of this step, I had a clear technical plan showing how the app would function and what needed to be built.

3. Code with Claude Code:

After preparing the technical plan, I moved on to the actual development. I gave the technical_plan.md to Claude Code and let it handle the setup. It read through the plan and started building the project step by step.

First, Claude Code created the project structure for me. It set up separate folders for backend and frontend, added all the necessary config files, and got the basic setup ready.

Next, Claude started building the core of the app. It took care of scaffolding, set up the main routes, created basic UI components, and wired everything together according to the plan. Claude did most of the heavy lifting.

There were some hiccups. A few files did not run on the first try. A few flows needed adjustments. Whenever something was off, I gave feedback, and Claude updated the code and retried the steps. After a few rounds, the flow was working.

Once the base version was ready, I used Claude Code to push it to GitHub using the GitHub MCP Server. It initialized the repo, added the remote, committed the files, and pushed the code, all in one go.

One thing I’ve noticed with AI tools is they are good at moving fast. Especially for POCs and early-stage builds. This speed is a huge advantage. But developer oversight is still important.

This is how Claude Code helped me get the base product ready.

With the scaffolded app in GitHub, I was ready to move on to the next stage. The next step was to review the code and fix any issues before continuing.

4. Code Review with CodeRabbit:

I reviewed the code using an AI code reviewer CodeRabbit. It works inside the editor and can also review pull requests.

This is how CodeRabbit showed reviews inside VS Code. It analyzed the entire codebase and added detailed feedback right inside VS Code. It pointed out potential issues, missing checks, CORS settings, and areas where the code could be improved or refactored. You can see comments on specific lines, and the right panel lists all the feedback in one place.

After each commit, it asked whether to review the changes. This made it easy to spot and fix issues right inside the editor.

5. Testing

For testing I just relied on the tools I already had in my stack.

I tested both the frontend and backend using Claude Code, either directly or with a helper tool.

Testing the UI

To test the UI, I used the Playwright MCP Server along with Claude Code. The UI lets users upload their photo and a garment image. I checked if both uploads worked, if the try on button stayed disabled until both images were picked, and if the layout looked fine across browsers. The tests ran in headless mode and gave a simple pass or fail for each check. This covered the main user flows I wanted to test.

Testing the API

For backend testing, I asked Claude Code to scan the codebase and list the available API endpoints for testing.

Claude Code generated the curl commands needed to test each API endpoint, covering both synchronous and asynchronous flows.

Here, Claude Code used curl commands to test the API with sample images. It asked me for confirmation before running each test.

After running the tests, I checked the results for job creation, fetching the processed image, and deleting a job. The responses confirmed that each API step worked as expected. Finally, Claude Code gave a summary, confirming that all the API endpoints had been tested successfully.

6. Deployment

Here’s how I handled deployment for both frontend and backend using Claude Code and two different MCP servers.

This diagram shows the deployment workflow. The frontend was deployed using the Netlify MCP Server, and the backend was deployed using the Railway MCP Server.

Frontend Deployment

I configured Netlify MCP Server with Claude Code, and I asked Claude to deploy the frontend. There were few issues during the first attempt, but Claude Code resolved them and deployed successfully. After the deployment, the frontend was live at the given Netlify URL.

The Netlify Console confirmed that the frontend was deployed successfully.

Backend Deployment

Next, I used Claude Code to deploy the backend using the Railway MCP Server. It set the environment variables, triggered deployment, and confirmed the API was live.

The Railway Console showed that the API was up and running.

Connecting Frontend and Backend

Once both parts were live, I needed to integrate them.

Initially, I faced CORS and Content Security Policy (CSP) issues that blocked API requests from the frontend to the backend.

After adjusting the CORS headers and updating the CSP config, the frontend was able to communicate with the backend. The UI loaded correctly, and I could upload images and start the try-on workflow.

Here's the final working app I built entirely with AI tools - Virtual Try-On Fashion App.

The application infrastructure works well. Users can upload images, trigger the try-on process, and receive results. The garment fitting isn't perfect since the underlying method simply merges images rather than realistic fitting, but the complete full-stack workflow functions as intended.

This shows that AI tools can assist at every stage of full-stack development and help us deliver functional applications.

Some Visuals from the App:

Deployment Notes for Developers

If you are building a POC, these free-tier platforms can help,

• For frontend: Vercel, Render, or Netlify.

• For backend: Render or Railway.

I used Railway for the backend deployment. Because Render’s MCP Server does not support free-tier API deployments through Claude Code.

However, you can still do the free deployment using Render manually through the console.

Conclusion

After building this app, using AI Agents at every stage, I got a clear picture of what is possible today. From product planning to code implementation, testing, and deployment, AI agents like Traycer, Claude Code, and CodeRabbit helped move things faster and with less manual effort.

There were a few bumps along the way, especially with integration and some areas where the AI could do better. But for building a prototype or testing new ideas, this approach works well.

If you want to speed up development or cut down on manual steps, it is worth trying an AI-first workflow. Just make sure to spend enough time on planning. The clearer the plan, the better the results you get from the tools.

Hope you found this post useful.

Happy Learning!

Initially, adoption was slow. The main reason? Accessing Claude Code required a separate Anthropic API key, which needed to be topped up with credits. In other words, even if you were a Claude Pro or Max subscriber, you still needed to pay extra to use Claude Code.

Many developers stayed away because of this cost issue.

However, Anthropic recently made a significant announcement. Claude Pro/Max users can now access Claude Code as part of their existing Pro ($20) or Max Plan ($100), with some usage limits. This update made Claude Code available to all paid Claude users.

With this change, more developers have started to use Claude Code. However, many people are still unsure about how to get started or how to make the most of its features.

So, I write this post to cover everything about Claude Code. The first part of this blog covers Claude Code setup and key features like slash commands, hooks, and MCP server integration. The second part includes useful GitHub repos for Claude Code, developer workflows, and pro tips, all in one place.

We'll cover:

Part 1: Claude Code Basics

1. Installation and first run

2. Custom slash commands

3. Claude Code Hooks

4. Claude Code Memory

5. MCP integration, and IDE setup

Part 2: Claude Code Collections and Developer Workflows

1. Collections of Custom slash commands

2. Collections of Claude Code Hooks

3. Collections of claude.md files

4. Collections of Essential MCP servers

5. Build GitHub Actions workflow with Claude Code

6. Work on Multiple Features with Git Worktrees in Claude Code

7. Automate Your Development Workflow with Claude Code

8. Calculate Your Claude Code Usage

9. How to justify the $100 Max plan

10. Ten Pro Tips for Claude Code

Let us get started!

Part 1: Claude Code Basics

Claude Code is a terminal-based coding agent from Anthropic. It's now the latest alternative to Cursor. Since it runs in the terminal, you can use it with any IDE or your existing workflow.

1.1 Installation and First Run

Setting up Claude Code is straightforward. Ensure you have Node.js 18 or newer and a supported operating system such as macOS, Linux, or Windows with WSL.

Install Claude Code with npm:

npm install -g @anthropic-ai/claude-code
cd your-project-directory
claude

Do NOT use "sudo npm install -g" as this can lead to permission issues.

Authenticate with your Anthropic account on first run. Make sure you have a Pro or Max subscription to access it without extra API costs.

1.2 Slash Commands

Claude Code comes with built-in slash commands. It makes working with Claude Code much easier. Explore commands by typing /help or just start typing / to see the full list.

Custom slash command

Claude Code lets you create custom slash commands. These are basically shortcuts for prompts you use often. Instead of typing the same prompts over and over, you create a command and reuse it.

There are two types of custom commands you can create,

• Personal Commands (will be available across all your projects)

• Project Commands (specific to a single project)

Creating Personal (user) Command:

a. Create a markdown file and place your file in ~/.claude/commands/.

cd /home/user-name
mkdir -p .claude/commands
vi cleanup.md

b. Write all your prompt instruction in that markdown file. Use $ARGUMENTS for dynamic variables.

#cleanup.md

Analyze $ARGUMENTS and identify dead code:
- Unused functions and methods
- Unreachable code paths
- Unused imports and dependencies
- Commented-out code blocks
- Obsolete configuration files

Provide a cleanup plan with safe removal suggestions and potential impact analysis.

c. Save the markdown. Now use /cleanup in Claude Code to run your instruction.

Usage examples:

"/cleanup src/components" to clean a directory, "/cleanup UserService.js" to clean a file, and "/cleanup authentication" to clean a specific feature.

I tried this on my codebase. Here's how it worked based on the instruction given in the cleanup.md file.

Creating Project Command:

Project commands live in project_dir/.claude/commands/ and are only visible within that project.

a. Create the markdown file inside your project.

cd your-project-directory
mkdir -p .claude/commands
vi security-review.md

b. Add your prompt and save.

#security-review.md

Review this code for security vulnerabilities.
Suggest fixes for any security issues you find.
Highlight any risky dependencies or unsafe patterns in the code.

c. Now you can use /security-review in your project.

Organizing Commands with Folders

You can organize commands in subdirectories for better structure.

project_root/.claude/commands/

├── frontend/
│   └── code-refactor.md
├── backend/
│   └── build-api.md
└── utils/
    └── create-README.md

When organized this way, Claude Code displays folder names with slash commands. It makes easy to find what you need.

Quick Tips

• Keep commands simple and focused.

• Use $ARGUMENTS to pass dynamic inputs.

1.3 Claude Code Hooks

Claude Code Hooks are user-defined shell commands that run at specific points in your workflow. Because these hooks execute without confirmation, it’s important to make sure they are safe and secure.

a. Create hooks using /hooks command.

b. Choose when your hook should run (e.g., before a tool runs, after it runs, on notifications, etc.).

c. Once the hook event is selected, Add New Matcher

d. Type Bash for the matcher. Find the various matchers for PreToolUse.

e. Click Add New Hook. and enter the command that needs to be run,

f. Save the hook either at user or project level.

g. Once added you can see your hooks with /hooks list.

We selected PreToolUse as hook event. It means every time Claude Code is about to execute any prompt, your hook script will run first. If your script finds any issues, it can even stop the process right there.

This is a simple example of how effectively we can use hooks.

Hooks settings in Claude Code are saved in settings files. You can set them for yourself or for your whole project.

1.4 Claude Code Memory

Claude Code has a memory feature called the CLAUDE.md file. This is the first file it reads with every prompt. Add your project details, coding standards, build steps, or anything else you want Claude to remember, just like Cursor rules.

Memory Types

Claude Code supports three memory types. Each one serves a different purpose.

Command to Create CLAUDE.md

Run /init to bootstrap the file. Choose the memory type and location.

Command to Edit CLAUDE.md

Use /memory to edit

Quickly add memories with the # shortcut

To add memory fast, write your input with the `#` character and enter.

What you can write in CLAUDE.md

CLAUDE.md can contain any information you want Claude Code to remember about your project. It can have project overview, commands, coding standards, folder structure, design notes, links to docs, etc.

Below are some examples

project preferences

See @README for project overview and @package.json for available npm commands for this project.

# Additional Instructions
- git workflow @docs/git-instructions.md

personal preferences

# Individual Preferences
- @~/.claude/my-project-instructions.md

Let us now see how to add MCP Servers in Claude Code.

1.5 MCP Integration and IDE Setup

We can connect Claude Code to different MCP Servers.

• Stdio MCP Server (Local or npm/PyPI MCP Server using stdio transport)

• SSE MCP Server (Remote MCP server using SSE as transport)

• Streamable HTTP MCP Server (Remote MCP server using HTTP streaming)

Adding Stdio MCP Server

# Basic syntax
claude mcp add <name-for-server> -s <scope> <command> [args...] -e <env-variables>

For example, I added the Notion MCP server with user-level scope and custom environment variables.

• Use -s to set the scope (e.g., user or project)

• Use -e to pass environment variables

I also tested it.

Adding SSE MCP Server

I built an SSE-based MCP server long back, so let’s try adding that now.

Add "--transport SSE" Flag for SSE Server

And it works like below.

Note that MCP originally used HTTP + SSE for transport. It now supports the improved HTTP Stream transport but still remains compatible with SSE. If you want to know more about the MCP transport, please check this page.

So let us now try connecting the latest HTTP Stream MCP Server.

Adding Streamable HTTP MCP Server

I built an MCP server that uses HTTP stream transport. This server deploys your web app to Vercel or Render based on your input. I connected it to Claude Code using the --transport http flag.

Explore MCP Servers using /mcp command.

Import MCP Servers from Claude Desktop

If you have MCP servers configured in Claude Desktop, you can import them into Claude Code with a single command.

claude mcp add-from-claude-desktop