Data Science In Action

[CCAR-F-Part 11] What Domain 4 Actually Covers: Prompt Engineering and Structured Output

Engy Fouda — Thu, 03 Sep 2026 18:43:03 GMT

This is part of the Claude Certificate Architect-Foundations:

[CCAR-F-Part1] The Five Domains That Matter for Claude Architect Certification
[CCAR-F-Part2] How to Pass the Claude Architect Certification: A Step-by-Step Preparation Guide?
[CCAR-F-Part 3] The Six Scenarios You Will Face on the Claude Architect Exam
[CCAR-F-Part 4] How to Prepare for Each of the Six Exam Scenarios?
[CCAR-F-Part 5] What Domain 1 Covers: Agentic Architecture and Orchestration
[CCAR-F-Part 6] Building Every Domain 1 Pattern: A Complete Implementation Guide
[CCAR-F-Part 7] What Domain 2 Actually Covers: Tool Design and MCP Integration
[CCAR-F-Part 8] Building Every Domain 2 Pattern: A Complete Implementation Guide
[CCAR-F-Part 9] What Domain 3 Actually Covers: Claude Code Configuration and Workflows
[CCAR-F-Part 10] Building Every Domain 3 Pattern: A Complete Implementation Guide

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

What Domain 4 Actually Covers: Prompt Engineering and Structured Output

Six distinct skills fall under this domain, from writing review criteria specific enough to trust to knowing when a second independent reviewer beats a longer thinking budget

Domain 4 accounts for 20 percent of the exam, tied with Domain 3 as the second-largest domain. It is also the domain most directly tied to whether people actually trust what Claude produces, since it covers the difference between output that looks plausible and output you can safely automate around. Here is the complete picture.

Topic 1: Designing Prompts With Explicit Criteria

The instinct most people reach for first, when Claude’s output has too many false positives, is to tell it to “be more conservative” or “only report high confidence findings.” This does not work as well as it sounds like it should. Vague qualifiers like these give Claude nothing concrete to apply consistently, so the false-positive rate barely changes.

What actually works is replacing vague qualifiers with explicit, categorical criteria. Instead of “check that comments are accurate,” a stronger instruction states precisely what counts as a violation: flag a comment only when the claimed behavior directly contradicts what the code actually does, not when a comment is merely incomplete or could be phrased better. This distinction matters because false positives compound in a specific way. Once one category of findings turns out to be unreliable, it erodes trust in every other category, even the ones that were accurate all along. Sometimes the right short-term fix is not a better prompt at all, but rather temporarily turning off a high-false-positive category entirely while the underlying criteria are reworked.

Topic 2: Few-Shot Prompting for Output Consistency

Detailed written instructions can only get you so far before a task becomes genuinely ambiguous. Few-shot examples, a small handful of worked examples embedded directly in the prompt, are the more reliable fix once instructions alone start producing inconsistent results.

The value of a good few-shot example goes beyond format demonstration. An example that also shows the reasoning behind a choice, why this particular action was selected over another plausible one, teaches Claude to generalize that judgment to genuinely novel cases it has not seen before, rather than only matching the exact scenarios you happened to demonstrate. This same technique reduces hallucination directly in extraction tasks: showing a few examples of correct extraction from documents with unusual or varied structure, inline citations versus a separate bibliography, for instance, meaningfully improves handling of documents that do not match whatever structure you expected by default.

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

Topic 3: Enforcing Structured Output With Tool Use and JSON Schemas

Asking Claude to “respond in JSON” inside a plain text prompt produces output that is close to valid JSON most of the time, and that gap between close and guaranteed is exactly the problem. Tool use with a JSON schema closes that gap completely for syntax. When a schema is enforced through tool use, the output is guaranteed to be syntactically valid, with no more malformed brackets or missing commas to catch downstream.

It is important to be precise about what this guarantee does and does not cover. Schema enforcement eliminates syntax errors. It does not eliminate semantic errors, a set of line items that fail to sum to the stated total, or a value placed in a field that is technically the right type but the wrong meaning. Those still require separate validation. Schema design itself carries real judgment, too: marking a field as required when the source document might genuinely lack that information pressures the model to invent a plausible-sounding value rather than admit the information is absent, so fields that are legitimately sometimes missing should be nullable, not required.

Share Data Science In Action

Topic 4: Validation, Retry, and Feedback Loops

A failed extraction is not always the same kind of failure, and treating every failure the same way wastes retries that were never going to succeed. When a follow-up request includes the original document, the failed extraction, and the specific validation error raised, Claude has a real chance of self-correcting, which works well for structural or formatting mismatches.

It works far less well when the actual problem is that the required information does not exist anywhere in the source document. No amount of retrying will produce a customer’s phone number from a document that never mentions one. Recognizing which category a given failure falls into -fixable through retry versus fundamentally unfixable because the data was never there- is the actual skill being tested here, more than the retry mechanism itself. There is also a longer-term feedback loop worth building: tagging each finding with the specific pattern that triggered it lets you later analyze which patterns developers consistently dismiss as false positives, turning individual corrections into a systematic signal.

Give a gift subscription

Topic 5: Designing Efficient Batch Processing Strategies

The Message Batches API offers a real, meaningful tradeoff: roughly 50 percent cost savings, in exchange for a processing window of up to 24 hours with no guaranteed latency. That tradeoff makes batch processing an excellent fit for workloads that can tolerate waiting, an overnight technical debt report, a weekly audit, nightly test generation, and a poor fit for anything blocking, like a pre-merge check a developer is actively waiting on before they can proceed.

One structural limitation is worth noting regardless of which side of that tradeoff you land on: the batch API does not support multi-turn tool calling within a single request, so you cannot have a batch job call a tool mid-request and receive the result in that same call. Each request and response pair in a batch is correlated through a custom_id field, which becomes essential when handling partial failures, since you resubmit only the specific documents that failed, identified by that ID, rather than reprocessing an entire batch from scratch.

Topic 6: Designing Multi-Instance and Multi-Pass Review Architectures

A model reviewing its own freshly generated output tends to be a weaker reviewer of that output than a genuinely separate instance would be. This is not a minor effect. The same session retains its own reasoning context from having just generated the content, which makes it measurably less likely to question decisions it only just made, even when a fresh perspective would catch the issue immediately.

There is a second, related failure mode this domain covers: reviewing many files together in a single pass tends to produce inconsistent depth, and sometimes outright contradictory verdicts, flagging one pattern as problematic in one file while approving the identical pattern elsewhere in the same batch. The fix for both problems is architectural rather than a better prompt. An independent review instance, with no access to the generator’s own reasoning, catches issues self-review tends to miss. And splitting a large review into focused, per-file passes for local issues, followed by a separate integration pass for cross-file consistency, avoids the attention dilution that leads to contradictory findings in a single oversized pass.

Refer a friend

Why All Six Matter Together

These six topics form a pipeline more than a list. Explicit criteria (Topic 1) and few-shot examples (Topic 2) shape what Claude produces in the first place. Schema enforcement (Topic 3) guarantees that output is structurally usable. Validation and retry loops (Topic 4) catch what schema enforcement alone cannot. Batch processing (Topic 5) determines how that pipeline scales economically across volume. And multi-instance review (Topic 6) is the final check that catches what the generating pass, however well configured, still misses on its own.

The next article in this series builds on each of these six topics with real, runnable code, including two scenarios pulled directly from the certification exam guide’s sample questions.

Leave a comment

Subscribe to Data Science In Action for the full implementation guide.

#Claude #CertifiedArchitect #AI #PromptEngineering #Certification #DataScienceInAction

[CCAR-F-Part 10] Building Every Domain 3 Pattern: A Complete Implementation Guide

Engy Fouda — Tue, 01 Sep 2026 16:09:42 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

Building Every Domain 3 Pattern: A Complete Implementation Guide

Article 9 covered what Domain 3 actually includes: CLAUDE.md hierarchy, custom commands and skills, path-specific rules, plan mode versus direct execution, iterative refinement, and CI/CD integration. This article builds each one, in order, with real configuration and command examples, and where the exam guide has a matching sample question, that exact question is shown alongside the fix.

How this article aligns with the exam’s scenarios. Domain 3 is the primary domain for Scenario 2 (Code Generation with Claude Code) and a primary domain for Scenario 4 (Developer Productivity with Claude) and Scenario 5 (Claude Code for Continuous Integration). Parts 2, 4, and 3 below are built as direct matches to the exam guide’s Questions 4, 5, and 6, all under Scenario 2, and Part 6 matches Question 10 under Scenario 5. Every part names which scenario it fits.

Unlike the previous two articles, most of what follows is configuration and CLI usage rather than Python. Where a part is in Python, it is clearly labeled.

Part 1: CLAUDE.md Hierarchy

Save the project-level file as CLAUDE.md at your project root.

Maps to Task Statement 3.1: Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization.

# Project CLAUDE.md — checked into version control, applies to everyone

## Coding standards
- Use TypeScript strict mode for all new files
- Prefer functional components with hooks in React code
- All API handlers use async/await, never .then() chains

## Testing
See @.claude/rules/testing.md for detailed conventions.

## Package-specific standards
- API package: @packages/api/CLAUDE.md
- Frontend package: @packages/frontend/CLAUDE.md

Notice the @ prefixed references. This is the @import syntax, and it is what keeps a large monorepo’s CLAUDE.md from becoming an unreadable wall of text. A contributor working only in the frontend package never has to scroll past API-specific conventions to find what applies to them, since those live in a separate, imported file scoped to that package.

Compare this against a user-level file, which lives outside the project entirely:

# ~/.claude/CLAUDE.md — personal only, never shared via version control

I prefer verbose explanations when Claude Code proposes a refactor.

How this connects to the exam: the most common failure mode Task Statement 3.1 names directly is a new team member not receiving instructions everyone else follows, because those instructions were placed at the user level instead of the project level. If you are ever debugging inconsistent behavior across a team, the fastest diagnostic tool is the /memory command run inside Claude Code that lists exactly which memory files are currently loaded for that session. It will immediately reveal whether a project-level file is actually being picked up.

Which scenario this applies to: Scenario 2 (Code Generation with Claude Code), where CLAUDE.md configuration is named as a primary domain, and Scenario 4 (Developer Productivity with Claude).

Part 2: Custom Slash Commands

[CCAR-F-Part 9] What Domain 3 Actually Covers: Claude Code Configuration and Workflows

Engy Fouda — Fri, 28 Aug 2026 15:30:24 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

What Domain 3 Actually Covers: Claude Code Configuration and Workflows

Six distinct skills fall under this domain, from CLAUDE.md file hierarchy to knowing exactly when plan mode earns its cost

Domain 3 accounts for 20 percent of the exam, tied with Domain 4 as the second-largest domain after Agentic Architecture. It is also the domain most directly tied to day-to-day developer experience, since it covers the configuration choices a team makes once and then lives with for months. Here is the complete picture.

Topic 1: CLAUDE.md Hierarchy, Scoping, and Modular Organization

CLAUDE.md files exist at three levels, and which level you use determines who actually receives your instructions.

A user-level file, at ~/.claude/CLAUDE.md, applies only to that one person. It is not shared with teammates through version control, no matter how carefully it is written.
A project-level file, at the project root or in .claude/CLAUDE.md, is checked into the repository and applies to everyone who clones it.
A directory-level file applies only within that specific subdirectory.

This distinction explains one of the most common configuration problems teams run into: a new team member who somehow is not receiving instructions everyone else follows. The instructions almost always turn out to be sitting in that person’s own user-level file from a previous project, or in someone else’s user-level file, rather than in the project-level file that would actually propagate through version control.

Once a project level CLAUDE.md grows large, there are two ways to keep it manageable:

The @import syntax lets you reference external files from within CLAUDE.md, so a monorepo can pull in only the standards relevant to each package rather than forcing every contributor to read conventions for parts of the codebase they never touch.
Separately, the .claude/rules/ directory lets you split a monolithic file into focused, topic-specific files, such as testing.md or deployment.md, instead of one long document covering everything at once.
When something is behaving inconsistently across sessions, the /memory command shows exactly which memory files are currently loaded, which is the fastest way to diagnose a hierarchy problem rather than guessing.
Share

Topic 2: Custom Slash Commands and Skills

Slash commands and skills solve a similar problem to CLAUDE.md, team-wide availability versus personal customization, but for reusable workflows rather than passive instructions.

Project-scoped commands live in .claude/commands/ and are shared with the whole team through version control.
User-scoped commands live in ~/.claude/commands/ and are personal.
Skills work similarly but live in .claude/skills/, each with a SKILL.md file that supports its own frontmatter configuration.

Three frontmatter options matter most:

context: fork runs the skill in an isolated subagent context so its output, which can be verbose, does not pollute the main conversation.
allowed-tools restricts exactly which tools the skill can use while it runs, which matters when a skill should only ever write files and never delete or execute anything.
argument-hint prompts a developer for required parameters when they invoke the skill without providing them.

The distinction worth internalizing is when to reach for a skill versus a CLAUDE.md entry:
CLAUDE.md is for universal, always loaded standards.
Skills are for on-demand, task-specific workflows you invoke only when relevant.

Thanks for reading Data Science In Action! This post is public so feel free to share it.

Topic 3: Path-Specific Rules for Conditional Convention Loading

Directory-level CLAUDE.md files work fine when your conventions map cleanly onto your folder structure. They break down when they do not, and the clearest example is test files. If your test files live alongside the code they test, scattered across dozens of directories, a directory level CLAUDE.md cannot apply testing conventions uniformly, since there is no single directory that contains all your tests.

The fix is .claude/rules/ files that use YAML frontmatter with a paths field containing glob patterns, such as paths: ["**/*.test.tsx"]. A rule like this loads only when you are editing a file matching that pattern, regardless of which directory it lives in. This keeps irrelevant context and token usage down, since a rule about Terraform conventions never loads while you are editing a React component, even if both happen to sit in the same parent folder.

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

Topic 4: Plan Mode Versus Direct Execution

This is the decision most people either overthink or underthink, and the exam tests both directions.

Plan mode is built for tasks with real architectural weight: large-scale changes, multiple genuinely valid approaches, decisions about module boundaries, or changes that touch dozens of files. It lets you explore the codebase and design an approach safely before committing any changes, which matters because costly rework is exactly what happens when those decisions are made mid-implementation rather than before.

Direct execution is appropriate for changes that are simple and well-scoped, such as a single-file bug fix with a clear stack trace, or adding one validation check to a single function. Forcing plan mode onto a change like that adds overhead without adding value, since there is no meaningful decision to plan around.

One additional tool worth knowing here is the Explore subagent, which isolates verbose discovery output, the kind of noisy, exploratory searching a complex task generates, and returns a clean summary instead, preserving the main conversation’s context for the actual implementation work that follows.

Refer a friend

Topic 5: Iterative Refinement Techniques

Getting a good result from Claude Code on the first try is not always realistic for ambiguous or unfamiliar tasks, and this domain covers techniques for progressively improving results rather than restarting from scratch each time.

Concrete input and output examples communicate a transformation far more reliably than a prose description does, especially when a written description keeps getting interpreted inconsistently across attempts. Test-driven iteration flips the usual order: write the test suite first, then iterate by sharing the actual test failures, which gives Claude Code something concrete to correct against rather than a vague sense of what “working” means. The interview pattern has Claude Code ask you clarifying questions before implementing, surfacing considerations like cache invalidation strategy or failure handling that you might not have thought to specify upfront.

There is also a sequencing decision worth considering: when multiple issues interact, describing them together in a single detailed message tends to work better than addressing them one at a time, since a fix for one issue in isolation can conflict with a fix needed for another. Independent, unrelated issues are the opposite case and are better handled sequentially.

Give a gift subscription

Topic 6: Integrating Claude Code Into CI/CD Pipelines

Running Claude Code inside an automated pipeline, with no person available to respond to a prompt, requires a few specific configuration choices. The -p flag, short for print, runs Claude Code in non-interactive mode: it processes the prompt, writes the result to standard output, and exits, rather than waiting indefinitely for input that will never come. Pair this with --output-format json and --json-schema to get machine-parseable, structured findings back, the format an automated pipeline actually needs to post something like an inline pull request comment.

CLAUDE.md still matters here, providing the CI-invoked agent with project context, such as testing standards and review criteria, that it would otherwise have no way to know.

There is also a reliability point worth remembering: the same session that generated a piece of code tends to be a weaker reviewer of that same code, since it retains its own reasoning and is less inclined to question decisions it just made. An independent review instance, without that inherited context, catches issues a self-review pass tends to miss.

Get a group subscription

Why All Six Matter Together

These six topics build on each other in practice. A well-organized CLAUDE.md hierarchy (Topic 1) does nothing if a new teammate’s instructions are trapped at the wrong scope level. Path-specific rules (Topic 3) exist because directory-level CLAUDE.md files (also Topic 1) cannot handle conventions that cross directory boundaries. Choosing plan mode correctly (Topic 4) sets up the iterative refinement techniques (Topic 5) that follow it. And CI/CD integration (Topic 6) depends on the same configuration discipline established in Topics 1 through 3 actually being in place before an automated pipeline ever runs.

The next article in this series builds each of these six topics with real, runnable examples, including four situations pulled directly from the certification exam guide’s own sample questions.

Subscribe to Data Science In Action for the full implementation guide.

Leave a comment

#Claude #CertifiedArchitect #AI #ClaudeCode #Certification #DataScienceInAction

[CCAR-F-Part 8] Building Every Domain 2 Pattern: A Complete Implementation Guide

Engy Fouda — Wed, 26 Aug 2026 14:01:42 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

Building Every Domain 2 Pattern: A Complete Implementation Guide

Article 7 covered what Domain 2 actually includes: tool interface design, structured error responses, tool distribution and tool choice, MCP server integration, and built-in tool selection. This article builds each one in order with runnable code and, where the exam guide has a matching sample question, shows that exact question alongside the fix.

How this article aligns with the exam’s scenarios. Domain 2 is tested most heavily in Scenario 1 (Customer Support Resolution Agent), Scenario 3 (Multi-Agent Research System), and Scenario 4 (Developer Productivity with Claude). Part 1 below is built as a direct match to the exam guide’s Question 2, and Part 3 is built as a direct match to Question 9, both under their respective official scenarios. Every part names which scenario it fits so you can connect the technique to the context you are likely to see on exam day.

Setup

Every code block below is Python, except Part 4, which is a configuration file, not a script, and is labeled clearly when we get there. Each Python part is a standalone script, save it as its own file and run it independently with python filename.py.

pip install anthropic claude-agent-sdk
export ANTHROPIC_API_KEY="your-key-here"

The link to download the code for all of the parts of this article from my website is at the end of the article.

Part 1: Tool Description Design

Save as tool_descriptions.py, run with python tool_descriptions.py

Maps to Task Statement 2.1: Design effective tool interfaces with clear descriptions and boundaries.

Here is the exact problem from Question 2 in the official exam guide, under the Customer Support Resolution Agent scenario:

Production logs show the agent frequently calls get_customer when users ask about orders (e.g., “check my order #12345”), instead of calling lookup_order. Both tools have minimal descriptions (”Retrieves customer information” / “Retrieves order details”) and accept similar identifier formats. What is the most effective first step to improve tool selection reliability?

The correct answer is to expand each tool’s description to include input formats, example queries, edge cases, and explicit boundaries relative to similar tools; not to add few-shot examples, build a routing layer, or consolidate the tools. Below is the before and after.

import anthropic

client = anthropic.Anthropic()

# THE PROBLEM: two minimal, near-identical descriptions. Claude has almost
# nothing to differentiate them, especially for a request like "check my
# order #12345" which could plausibly sound like either a customer lookup
# or an order lookup if you are not reading closely.
weak_tools = [
    {
        "name": "get_customer",
        "description": "Retrieves customer information",
        "input_schema": {
            "type": "object",
            "properties": {"identifier": {"type": "string"}},
            "required": ["identifier"],
        },
    },
    {
        "name": "lookup_order",
        "description": "Retrieves order details",
        "input_schema": {
            "type": "object",
            "properties": {"identifier": {"type": "string"}},
            "required": ["identifier"],
        },
    },
]

# THE FIX from Question 2's correct answer: expand each description with
# input formats, example queries, and an explicit boundary statement
# against the similar tool. This is the "most effective first step" the
# exam guide names, ahead of few-shot examples, a routing layer, or
# consolidating the tools into one.
strong_tools = [
    {
        "name": "get_customer",
        "description": (
            "Retrieves a customer's account details (name, email, account status, "
            "membership tier) using their email address or customer ID. "
            "Use this when the request is about the CUSTOMER as a person or "
            "account, such as verifying identity, checking account status, or "
            "looking up contact details. Example queries: 'what is my account "
            "status', 'verify my identity', 'look up customer by email'. "
            "Do NOT use this for questions about a specific purchase or "
            "shipment, use lookup_order for those instead."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "identifier": {
                    "type": "string",
                    "description": "Customer email address or customer ID, not an order number.",
                }
            },
            "required": ["identifier"],
        },
    },
    {
        "name": "lookup_order",
        "description": (
            "Retrieves details about a specific PURCHASE or SHIPMENT (items, "
            "price, delivery status, return window) using an order ID. "
            "Use this when the request references a specific order, purchase, "
            "or shipment, especially when an order number is mentioned "
            "directly, such as 'check my order #12345' or 'where is my "
            "package'. Do NOT use this for general account questions, "
            "use get_customer for those instead."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "identifier": {
                    "type": "string",
                    "description": "Order ID, for example 'O456' or a number like '12345', not a customer email.",
                }
            },
            "required": ["identifier"],
        },
    },
]


def compare_tool_selection(user_message: str):
    for label, tool_set in [("WEAK descriptions", weak_tools), ("STRONG descriptions", strong_tools)]:
        response = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=200,
            tools=tool_set,
            messages=[{"role": "user", "content": user_message}],
        )
        called = [b.name for b in response.content if b.type == "tool_use"]
        print(f"{label}: called {called}")


if __name__ == "__main__":
    compare_tool_selection("Can you check my order #12345?")

How this connects to the exam: run this script and compare the two outputs. With the weak descriptions, tool selection can go either way, exactly the unreliability Question 2 describes. With the strong descriptions, the explicit “Do NOT use this for” boundary language and the concrete example query (”check my order #12345,” lifted directly from the question itself) give Claude enough signal to select lookup_order reliably. Task Statement 2.1’s skills list names this precisely: “Writing tool descriptions that clearly differentiate each tool’s purpose, expected inputs, outputs, and when to use it versus similar alternatives.”

Which scenario this applies to: Scenario 1 (Customer Support Resolution Agent), directly. This part is built as a faithful match to Question 2.

Subscribe now

Part 2: Structured Error Responses

Save as structured_errors.py, run with python structured_errors.py

[CCAR-F-Part 7] What Domain 2 Actually Covers: Tool Design and MCP Integration

Engy Fouda — Tue, 25 Aug 2026 14:03:46 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

What Domain 2 Actually Covers: Tool Design and MCP Integration

Five distinct skills fall under this domain, from writing tool descriptions Claude can reliably tell apart to knowing when Grep beats reading an entire file

Domain 2 carries 18% of the exam. It is smaller than Domain 1, but it is arguably more forgiving of shortcuts, since a poorly designed tool interface will produce visible, repeatable failures long before an exam question ever asks about it. This is also the domain most people underestimate, because tool design sounds like a small implementation detail rather than an architectural decision. It is not. Here is the complete picture

Subscribe now

Topic 1: Designing Tool Interfaces With Clear Descriptions and Boundaries

The single most important fact in this domain is this: the tool description is the primary mechanism Claude uses to decide which tool to call. Not the tool name. Not your system prompt, mostly. The description.

When two tools have minimal, near-identical descriptions, such as “Retrieves customer information” and “Retrieves order details,” Claude does not have enough signal to reliably distinguish between them, especially when a request could plausibly involve either one. The fix is not a longer system prompt telling Claude to be careful. The fix is to write descriptions that actually differentiate the tools: what inputs each one expects, example queries for each, edge cases, and explicit statements of when to use this tool versus a similar one.

There is a second, sneakier failure mode here too. Your system prompt can accidentally create tool associations through keyword sensitivity, even when your tool descriptions are perfectly fine. If your system prompt repeatedly uses language that happens to match one tool’s description more than another’s, Claude can develop a bias toward that tool regardless of what the request actually needs.

Topic 2: Structured Error Responses

When a tool fails, what you return matters as much as the failure itself. A generic “Operation failed” message gives Claude nothing to work with. It cannot decide whether to retry, try something else, or explain the problem to the user because it does not know what kind of failure occurred.

The fix is to categorize errors and return that category as structured metadata. Transient errors, such as timeouts or temporary unavailability, might succeed on retry. Validation errors, such as malformed input, will not. Permission errors need a completely different response than business rule violations. When you return an errorCategory field along with a retryable boolean and a human-readable description, Claude can make an appropriate recovery decision rather than guessing.

There is a related distinction worth internalizing here: an access failure, such as a timeout, is not the same as a valid empty result. A search that legitimately found nothing is a successful query with no matches, not an error. Treating both the same way, or worse, treating both as generic failures, hides information Claude needs to act correctly.

Topic 3: Distributing Tools Across Agents and Configuring Tool Choice

More tools does not mean a smarter agent. It usually means a less reliable one. Giving an agent eighteen tools instead of four or five measurably degrades the reliability of tool selection, simply because there is more to choose from and more room for confusion.

This becomes especially important in multi-agent systems. An agent given tools outside its actual specialization tends to misuse them, such as a synthesis agent that starts attempting web searches because it happens to have that tool available. The fix is scoped access: give each agent only the tools its role actually requires, and reserve broader cross-role tools for genuinely high-frequency shared needs.

Separately from which tools an agent has, you can also control how it uses them through the tool_choice parameter. Setting tool_choice to “auto” lets Claude decide whether to call a tool at all. Setting it to “any” forces Claude to use a tool rather than just respond with text. Forcing a specific named tool guarantees that exact tool runs, which is useful when a particular step, like extracting metadata, must happen before anything else can proceed.

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

Topic 4: Integrating MCP Servers

Model Context Protocol servers are how you wire external tools into Claude Code and agent workflows, and where you configure them matters. A project-scoped server, defined in a .mcp.json file at the project root, is shared with your whole team through version control. A user-scoped server, defined in your personal configuration, is just for you, useful for experimentation without affecting anyone else.

Credentials belong in environment variable references inside that configuration, not hardcoded values, so tokens never end up committed to your repository.

One detail that is easy to miss: tools from every MCP server you have configured become available simultaneously once connected. There is also a second MCP primitive worth knowing beyond tools: resources. Resources expose content catalogs, such as a list of available documents or a database schema, directly to the agent, reducing the number of exploratory tool calls it needs to make to figure out what exists.

Share Data Science In Action

Topic 5: Selecting Built-In Tools

Claude Code and Agent SDK-based agents come with built-in tools: Read, Write, Edit, Bash, Grep, and Glob. Knowing which one fits a given task is its own skill.

Grep searches file contents, useful when you need to find every place a function is called or every occurrence of an error message.
Glob matches file paths by pattern, useful when you need to find files by name or extension rather than by content.
Read and Write handle full file operations.
Edit makes a targeted change using unique text matching, and when that unique match cannot be found because the text appears more than once in the file, the reliable fallback is Read followed by Write instead of forcing Edit to work.

There is also a sequencing skill here. Effective codebase exploration usually starts with Grep to find entry points, then follows with Read to trace how things connect, rather than reading every file upfront and hoping the important parts stand out.

Give a gift subscription

Why All Five Matter Together

None of these five topics function in isolation. A well-scoped agent (Topic 3) still fails if its tool descriptions are ambiguous (Topic 1). A cleanly described tool can still cause downstream problems if its errors are generic (Topic 2). An MCP server correctly configured at the project level (Topic 4) is only useful if the agent calling it also has the right built-in tools available for the parts of the task that do not need MCP at all (Topic 5).

Refer a friend

The next article in this series builds on each of these five topics with real, runnable code, including two scenarios pulled directly from the certification exam guide’s sample questions.

Subscribe to Data Science In Action for the full implementation guide.

Leave a comment

#Claude #CertifiedArchitect #AI #MCP #ToolDesign #Certification #DataScienceInAction

[CCAR-F-Part 6] Building Every Domain 1 Pattern: A Complete Implementation Guide

Engy Fouda — Fri, 21 Aug 2026 20:49:55 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

Building Every Domain 1 Pattern: A Complete Implementation Guide

Runnable code for the agentic loop, all five workflow patterns, subagent configuration, and session management, with the exact exam task statements and sample questions each part demonstrates

Article 5 covered what Domain 1 actually includes: workflows versus agents, the agentic loop mechanics, task decomposition, five orchestration patterns, subagent configuration, and session state. This article builds each one, in order, with runnable code.

Domain 1 breaks down into seven official task statements (1.1 through 1.7) in Anthropic’s exam guide. Each part below names which task statement it demonstrates, and where the exam guide’s own sample questions test that exact concept, we show the question and explain how the code you just ran answers it.

How this article aligns with the exam’s scenarios. The certification tests Domain 1 through four of six randomly selected scenarios, not through the domain in isolation. Part 5 below is built as a direct, faithful match to Scenario 3 (Multi-Agent Research System) and its actual sample question from the exam guide. The other parts teach the underlying pattern using original examples, since these patterns apply across multiple scenarios rather than belonging to just one, but each part now names which official scenario would realistically call for that pattern, so you can connect the technique to the context you’ll actually see on exam day.

This is a longer tutorial than most in this series, because the domain itself is the largest on the exam at 27%. Work through it in sections rather than in one sitting if that suits you better.

Setup

Every code block in this guide is Python. Each part below is a separate, standalone script. Save it as its own file and run it independently with python filename.py. They are not meant to be pasted into one combined file.

pip install claude-agent-sdk anthropic

Then set your Anthropic API key as an environment variable. The command depends on which terminal you are using, so check your terminal’s title bar or prompt style against the three options below before running anything.

Command Prompt (cmd.exe on Windows, prompt looks like C:\Users\yourname>):

set ANTHROPIC_API_KEY=your-key-here

PowerShell (prompt looks like PS C:\Users\yourname>):

$env:ANTHROPIC_API_KEY="your-key-here"

Mac or Linux terminal (bash or zsh):

export ANTHROPIC_API_KEY="your-key-here"

A note for Windows users: Command Prompt and PowerShell look similar but are different programs with different commands. The export command only works in Mac, Linux, or WSL terminals, and will fail with a “not recognized” error in either Windows shell, since it does not exist there.

Also worth knowing, whichever shell you use: this environment variable only lasts for that terminal window’s current session. Close the window, and you will need to set it again the next time before running any script in this article.

You can download the code for all of the parts of this article from my website:

https://engyfoda.com/CCARF_Donamin1.zip

Part 1: The Agentic Loop, By Hand

Save as agentic_loop.py, run with python agentic_loop.py

Maps to Task Statement 1.1: Design and implement agentic loops for autonomous task execution.

Agentic loop: The repeating cycle where the model takes an action, observes the result, and decides the next action, continuing until the goal is met or a stopping condition fires.

Before using the SDK’s automatic loop handling, it is worth seeing the mechanism explicitly, using the raw Messages API. This is the piece that the SDK normally hides from you, and it is also where the exam guide lists specific anti-patterns to avoid.

import anthropic

client = anthropic.Anthropic()

# Tool definitions follow the standard Anthropic API schema: a name, a
# description the model uses to decide when to call it, and a JSON schema
# for the expected input.
tools = [
    {
        "name": "get_weather",
        "description": "Get the current weather for a city",
        "input_schema": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    }
]

def get_weather(city: str) -> str:
    # Mock implementation, replace with a real weather API call.
    return f"It is 68 degrees and partly cloudy in {city}."


def run_agentic_loop(user_message: str):
    # The conversation history. Every tool call and every tool result gets
    # appended here, so each new API call sees the full accumulated context.
    # This is what Task Statement 1.1 calls "tool results are appended to
    # conversation history so the model can reason about the next action."
    messages = [{"role": "user", "content": user_message}]

    while True:
        response = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )

        # Every turn, model or tool, gets appended before we decide what
        # happens next. Skipping this step is how context gets silently lost.
        messages.append({"role": "assistant", "content": response.content})

        # THIS IS THE PART THE EXAM TESTS DIRECTLY.
        # response.stop_reason is the actual, documented control signal for
        # the loop. "tool_use" means Claude wants to call a tool and the loop
        # should continue. "end_turn" means Claude considers the task done.
        #
        # The exam guide names three specific anti-patterns to avoid here:
        #   1. Parsing the assistant's natural language text to guess whether
        #      it's "finished" (unreliable, the model might describe finishing
        #      without actually being done, or vice versa)
        #   2. Using an arbitrary iteration cap as your PRIMARY stopping
        #      mechanism (a cap is fine as a safety net, but stop_reason
        #      should be what actually ends the loop)
        #   3. Checking for the presence of assistant text content as a
        #      completion indicator (Claude can write text AND still want
        #      to call a tool in the same turn)
        if response.stop_reason == "tool_use":
            tool_results = []
            for block in response.content:
                if block.type == "tool_use" and block.name == "get_weather":
                    result = get_weather(block.input["city"])
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": result,
                    })

            # The tool result gets appended as a user-role message, and the
            # loop continues by calling the API again with this new context.
            messages.append({"role": "user", "content": tool_results})
            continue

        if response.stop_reason == "end_turn":
            for block in response.content:
                if block.type == "text":
                    print(block.text)
            break


if __name__ == "__main__":
    run_agentic_loop("What is the weather like in Austin?")

The above code’s output

How this connects to the exam: Task Statement 1.1’s skills section states the correct approach almost word for word: “Implementing agentic loop control flow that continues when stop_reason is ‘tool_use’ and terminates when stop_reason is ‘end_turn’.” That is exactly the if response.stop_reason == logic above, and nothing else. If you ever find yourself writing code that checks if "done" in response_text or similar, that is the anti-pattern the exam is testing you to recognize and avoid.

stop_reason: A field on every API response saying why the model stopped.
1. tool_use = wants a tool (continue);
2. end_turn = finished (stop);
3. max_tokens = truncated (check for it);
4.stop_sequence = hit a custom stop.

Which scenario this applies to: the agentic loop underlies every Agent SDK scenario on the exam. Still, it is most directly tested in Scenario 1 (Customer Support Resolution Agent) and Scenario 3 (Multi-Agent Research System), since both are built on the Claude Agent SDK from the ground up.

Subscribe now

[CCAR-F-Part 5] What Domain 1 Covers: Agentic Architecture and Orchestration

Engy Fouda — Thu, 20 Aug 2026 17:45:19 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

Introduction

Domain 1 carries the most weight on the certification exam at 27 percent, more than any other domain. If you only study one topic deeply, this should be it. But it is also the domain most people misunderstand, because it sounds like it is about one thing (agents talking to other agents) when it actually covers six distinct topics that all fit under the umbrella of “how do you architect a system that uses Claude to get work done.”

Here is the complete picture.

Topic 1: Workflows Versus Agents

Before you design anything, you need to know which one you are building, because they are not the same thing.

A workflow is a predefined path. You, the developer, decide the sequence of steps in advance. The LLM fills in specific steps, but the control flow is yours. A workflow is predictable and easy to debug, because the same input roughly follows the same path every time.

An agent is different. Claude decides on its own process based on environmental feedback in a loop until the task is done. You do not predetermine the steps. Claude does.

Neither is better. Workflows offer predictability and consistency for well-defined tasks. Agents offer flexibility when you cannot predict the steps in advance, at the cost of less predictable behavior and higher latency. The exam tests whether you can look at a scenario and correctly identify which one fits.

A rule of thumb: if you can draw the flowchart of every possible path before you write any code, you probably want a workflow. If the number and nature of steps genuinely depends on what the agent discovers along the way, you want an agent.

Subscribe now

Topic 2: The Agentic Loop

An agent is, mechanically, an LLM using tools based on feedback, in a loop. Understanding what actually happens in that loop matters more than it might seem.

Here is the mechanism. Claude receives a message and decides what to do next. If it wants to use a tool, the API response comes back with a stop reason of tool_use. Your code runs the tool, and the result is appended to the conversation. Then Claude is called again with the updated context, and it decides what to do next, again. This repeats until Claude returns a stop reason of end_turn, meaning it believes the task is complete.

That stop reason is the actual control signal for the loop. It is not something you infer by parsing what Claude wrote in natural language. Checking stop_reason is the correct way to know whether to continue the loop. Trying to guess from the response text is a common mistake and a real anti-pattern that the exam will test you on.

If you use the Agent SDK, this loop is handled for you automatically. That is convenient, but it also means the mechanism is invisible unless you deliberately study it separately, which is worth doing, since exam questions about tool result handling assume you understand what is happening underneath the abstraction.

Topic 3: Task Decomposition

Whether you are building a workflow or an agent, you eventually have to decide how to break a large task into smaller pieces. This sounds simple, but it's actually one of the easiest places to get wrong.

Decompose too coarsely, and one step tries to do too much, producing unreliable results. Decompose too narrowly, and you create coverage gaps between the pieces, where something important falls through the cracks because no single step owned it.

The exam favors decomposition that matches the problem's actual structure, rather than an arbitrary number of steps. If a task naturally has three phases, force-fitting it into five steps for the sake of “more granularity” tends to introduce exactly the coverage gaps described above.

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

Topic 4: The Five Workflow Orchestration Patterns

This is the part most people skip past, and it is a meaningful chunk of Domain 1. There are five composable patterns for orchestrating workflows, each suited to a different problem shape.

Prompt chaining breaks a task into a sequence of steps, where each step’s output feeds the next, with validation gates in between. Use this for multi-step transformations that decompose cleanly, like generating an outline, then expanding it into a draft, then editing that draft.

Routing classifies an incoming request and directs it to a specialized handler built for that category. Use this when you have genuinely distinct categories of work that benefit from different handling, such as separating billing questions from technical support questions before either reaches a specialized prompt.

Parallelization runs multiple calls at once, either by splitting a task into independent pieces (sectioning) or by running the same task multiple times to compare results (voting). Sectioning suits independent subtasks that do not depend on each other. Voting suits situations where you want confidence through consensus, like having several passes review a piece of code for vulnerabilities.

Orchestrator-workers is the pattern most people mean by “multi-agent coordinator.” A central agent dynamically breaks down a task, delegates parts to worker agents, and then synthesizes their results. The key difference from parallelization is that the subtasks are not predefined. The orchestrator determines them at runtime based on the specific input's requirements. This is the pattern behind coding tools that touch multiple files, and research tools that need to search multiple sources without knowing in advance how many or which ones.

Evaluator-optimizer pairs a generator with a separate evaluator that critiques the output in a loop until it meets a quality bar. This works well when you have a clear evaluation criterion and when iterative refinement genuinely improves the result, such as in literary translation, where a first pass may miss nuances that a dedicated critique step can catch.

Notice that hub-and-spoke coordination is really just the orchestrator-workers pattern by another name. It is one of five. The exam expects you to recognize all five and pick the right one for a given scenario, rather than defaulting to the same pattern regardless of what the problem actually calls for.

Share Data Science In Action

Topic 5: Subagent Configuration

Once you have decided to use multiple agents, whether through orchestrator-workers or another multi-agent structure, you need to configure how they actually operate.

This covers context sharing (subagents do not automatically inherit the coordinator’s context, so you explicitly decide what each receives), spawning strategies (do you create subagents up front or dynamically as needed), and scoping (which tools and model each subagent has access to). A common anti-pattern here is giving every subagent the coordinator’s full context, which pollutes each subagent’s working context with information it does not need and can actively hurt its performance on its specific task.

Topic 6: Session State Management

The last piece of Domain 1 concerns persistence across turns and runs, not just within a single execution.

Continuing a session automatically picks up the most recent conversation. Resuming a session returns to a specific past session by its ID, which matters for multi-user applications where you cannot rely on “the most recent one.” Forking a session creates a new session from an existing one, preserving the original, which is useful when you want to try an alternative approach without losing the path you've already explored.

These are not just convenience features. The exam tests whether you know which one fits a given requirement: picking up where a process left off after a restart calls for continuing, letting a user return to a specific past thread calls for resuming with a captured ID, and exploring a different approach without disturbing existing work calls for forking.

Give a gift subscription

Why All Six Matter Together

Domain 1 is not a single skill. It is architectural judgment applied across six related decisions: whether to use a workflow or an agent, how the underlying loop actually functions, how to decompose the task, which of five orchestration patterns fits the problem shape, how to configure agents that work together, and how to manage state across turns and runs.

The certification exam scenarios will test combinations of these, not each one in isolation. A single question might require you to recognize that a scenario calls for orchestrator-workers rather than routing, while also expecting correct subagent context scoping, in the same answer.

Refer a friend

The next article in this series builds a complete, runnable implementation that covers each of these patterns with real code, so you can see the differences firsthand rather than just reading about them.

Subscribe to Data Science In Action for the full implementation guide.

#Claude #CertifiedArchitect #AI #Agents #Architecture #Certification #DataScienceInAction

Leave a comment

[CCAR-F-Part 4] How to Prepare for Each of the Six Exam Scenarios?

Engy Fouda — Tue, 18 Aug 2026 16:41:34 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

The last free article walked through what each of the six scenarios covers conceptually. This one is the study plan. For each scenario, you will get what to review, what mistakes to watch for, and a sample question so you can see exactly how the exam tests it.

Four of the six scenarios will appear on your exam. Since you will not know which four in advance, treat this as full coverage, then focus your most thorough review on whichever scenarios feel least familiar to you.

Scenario 1: Customer Support Resolution Agent

What to review: Identity verification as a required first step. Explicit escalation criteria (not confidence-based escalation). Programmatic enforcement for business-critical rules like refund thresholds and return windows.

Common mistake: Choosing an answer that relies on the agent “being careful” or “using good judgment” when the scenario involves money or account access. If the consequence of failure is financial or affects account security, the correct answer almost always involves a programmatic/deterministic check rather than a prompt instruction.

Sample question pattern: An agent occasionally processes refunds without first verifying the customer's identity. What is the best fix?

The correct approach is to make programmatic access to the refund tool a prerequisite, blocking access until identity verification is complete. An instruction telling the agent to “always verify first” is insufficient when the downside of getting it wrong is money leaving the business.

Give a gift subscription

Scenario 2: Code Generation with Claude Code

What to review: The configuration hierarchy (user, project, directory-level settings) and how path-scoped rules work. The distinction between plan mode and direct execution. CI/CD integration basics.

Subscribe now

[CCAR-F-Part 3] The Six Scenarios You Will Face on the Claude Architect Exam

Engy Fouda — Tue, 18 Aug 2026 15:26:08 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

If you read last week’s article on the five domains, you know what the exam covers conceptually. But here is something important: the exam does not ask you to define terms. It puts you inside six realistic scenarios and asks how you would handle specific situations within them.

Four of the six scenarios will appear on your exam, chosen randomly. You will not know which four until you sit down to take it. That means understanding all six is worth your time.

Here is what each one actually tests.

Subscribe now

Scenario 1: Customer Support Resolution Agent

You are building an agent that handles returns, billing disputes, and account issues for an e-commerce company. It has tools to look up customers, check orders, process refunds, and escalate to a human.

This scenario tests decision-making under ambiguity. When should the agent resolve something on its own, and when should it hand off to a person? The exam repeatedly pushes this because escalation logic is where most production agents fail. Escalate too often, and the agent is useless. Escalate too rarely, and customers get wrong answers on things that actually needed a human.

You will also see questions about identity verification (why this must happen first) and programmatic enforcement (why some rules cannot just live in a prompt).

Scenario 2: Code Generation with Claude Code

You are using Claude Code across a development team for code review, refactoring, and generating new code. Questions in this scenario cover how configuration works: user-level settings, project-level settings, and directory-specific rules that only load when relevant.

This scenario also tests when to use plan mode versus direct execution. Plan mode makes sense for changes with real architectural weight. Direct execution makes sense for small, well-defined fixes. The exam wants you to recognize the difference, not just know both modes exist.

Expect questions about wiring Claude Code into CI/CD pipelines too, since automated review before a human ever looks at a pull request is a common production pattern.

Scenario 3: Multi-Agent Research System

You have a coordinator agent that spawns specialists: one for web search, one for document analysis, one for synthesis, one for reporting. This scenario tests whether you understand the hub-and-spoke pattern, where all communication flows through the coordinator rather than agents talking directly to each other.

The trickiest questions here involve context passing. Subagents do not automatically know what other subagents found. If you do not explicitly pass findings forward, information disappears. The exam tests whether you understand this and can design around it.

You will also see error-handling questions: when one specialist fails, how should that failure propagate back to the coordinator so the system can recover rather than break?

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

Scenario 4: Developer Productivity Tools

You are building an agent that explores codebases, generates boilerplate code, and automates repetitive engineering tasks. This scenario leans on Claude Code’s built-in tools: Read, Write, Edit, Bash, Grep, and Glob.

Questions here test whether you know when to reach for a built-in tool versus when you need a custom MCP integration. They also test scoped access. Should this particular agent have Bash access, or does that create more risk than value for what it is doing?

Share Data Science In Action

Scenario 5: Claude Code in CI/CD

You are running Claude Code inside a pipeline for automated code review and test generation, with no human sitting at a keyboard watching it work. This scenario specifically tests non-interactive mode and structured output formats that a pipeline can parse and act on.

A recurring theme here is false positive management. If your automated reviewer flags every minor style preference as a blocking issue, developers will start ignoring it. The exam tests whether you understand how to calibrate the tool's strictness to keep it useful.

Refer a friend

Scenario 6: Structured Data Extraction

You are building a system that extracts structured data from documents, validates the output, and handles edge cases where extraction fails. This scenario tests JSON schema design specifically: required versus optional fields, and how nullable fields prevent the model from inventing data it could not actually find.

You will also see validation-retry loop questions. What happens when the first extraction attempt fails validation? A well-designed system does not just fail. It retries, providing feedback on what went wrong.

Give a gift subscription

Why the Scenario Format Matters

Notice what these six scenarios have in common. None of them are abstract. Each one drops you into a specific system with specific tools and asks how you would handle a specific situation inside it.

This means studying definitions will only get you partway. You need to have actually built something like each of these, or spent real time thinking through how you would do so. The exam is testing judgment under realistic constraints, not vocabulary.

If you have shipped a customer-facing agent, Scenario 1 will feel familiar. If you have configured Claude Code for a team, Scenario 2 will feel familiar. The scenarios you have not touched are the ones worth spending deliberate prep time on, since your instincts have not been built yet.

Subscribe to Data Science In Action for the full deep-dive series on each of these scenarios, coming over the next several weeks.

#Claude #CertifiedArchitect #AI #Agents #ProductionSystems #Certification #DataScienceInAction

Leave a comment

[CCAR-F-Part2] How to Pass the Claude Architect Certification: A Step-by-Step Preparation Guide?

Engy Fouda — Sat, 15 Aug 2026 14:02:44 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

Introduction

You’ve decided to get the Claude Certified Architect Foundations certification. Smart choice. This isn’t a test designed to trip you up. It’s a test designed to validate that you actually know how to build production systems with Claude.

If you have not read part 1 of this series, please go ahead and read it. It’s free.

If you’ve shipped anything with Claude, you already know most of what’s on the exam. What you need is to systematize that knowledge, then practice the specific question format.

This guide walks you through exactly how to do that.

Step 1: Map Your Hands-On Experience Against the Five Domains

Grab a notebook or a spreadsheet. For each domain, write down the last time you actually dealt with it in a system you built.

Domain 1: Agentic Architecture & Orchestration

Have you built a system where Claude calls tools? Yes, you have. Have you built a multi-agent system where one agent delegates to specialists? Maybe not. Write that down.

Subscribe now

Domain 2: Tool Design & MCP Integration

Have you designed tool descriptions? Have you configured MCP servers? Write down what you’ve done and what’s still unfamiliar.

Domain 3: Claude Code Configuration & Workflows

Have you written a CLAUDE.md file? Used plan mode? Integrated MCP into Claude Code? Mark what’s real experience and what’s still theoretical.

Domain 4: Prompt Engineering & Structured Output

Have you used few-shot examples? Designed JSON schemas for structured output? Implemented validation-retry loops? List your experience.

Domain 5: Context Management & Reliability

Have you handled escalation decisions in a real agent? Managed error propagation across multiple agents? Designed human-in-the-loop workflows? This is where real systems get complicated.

What you’re doing here: Identifying where your experience is solid versus where you have gaps. The exam scenarios will test all five domains. Your goal is to walk into that exam knowing exactly which scenarios will feel familiar and which ones will push you.

Thanks for reading Data Science In Action! Share the article!

Step 2: Study the Five Exam Scenarios

The certification doesn’t give you random questions in isolation. It presents you with realistic scenarios, then asks questions grounded in those scenarios. There are six possible scenarios. Four will appear on your exam, randomly selected.

[CCAR-F-Part1] The Five Domains That Matter for Claude Architect Certification

Engy Fouda — Fri, 14 Aug 2026 14:38:46 GMT

This is a part of the Claude Certificate Architect-Foundations:

Download the official exam guide PDF at this link:

Claude Certified Architect-Foundation Exam Guide

Subscribe now

You’re reading about Claude certifications, which means you’ve built something real. Maybe you’ve used Claude to automate a workflow, or you’ve deployed an agent into production and had to debug it at 2 AM when something went wrong. Now you’re considering getting certified. Not just to have a credential, but to prove you actually know how to ship with Claude at scale.

The Claude Certified Architect Foundations exam tests five specific domains. Understanding what these domains represent isn’t about memorizing content. It’s about recognizing that each one solves a real production problem you’ve probably already encountered, or will encounter soon.

Subscribe now

Domain 1: Agentic Architecture & Orchestration (27%)

This is about building systems where Claude makes decisions, not about hard-coding every path. An agentic loop checks what Claude wants to do next. Does it want to call a tool? Are we done? The loop executes that tool and feeds the result back so Claude can reason about the next step. Simple in theory. Devilishly tricky in practice when you have multiple agents talking to each other, or when one agent needs to delegate work to specialists.

The certification tests whether you understand when a coordinator agent should route a question directly versus breaking it into subtasks for specialized subagents. It tests whether you can pass context between agents without losing critical information. These aren’t quiz questions about how loops work. They’re questions about decisions you actually make when designing systems.

Domain 2: Tool Design & MCP Integration (18%)

Here’s the thing about tools: Claude can only use what you give it. If your tool descriptions are vague, Claude will misuse them. If you give an agent fifteen tools when it only needs five, it gets confused about which tool to call and when to call it.

This domain is about making intentional choices. Should this agent have access to this tool, or would that create more problems than it solves? If you have two tools that do similar things, how do you describe them clearly enough that Claude reliably picks the right one?

Model Context Protocol (MCP) is the standard way to wire tools into Claude. The certification covers configuring MCP servers, designing tool descriptions that are actually useful, and handling errors in ways that let your system recover intelligently instead of just failing.

Domain 3: Claude Code Configuration & Workflows (20%)

Claude Code is the IDE integration. It’s how you tell Claude how your team likes to work. You write rules once in a CLAUDE.md file, and every developer on the team gets those conventions automatically.

But configuration goes deeper than just writing a file. You can scope conventions to specific file paths, so test file rules load only when you’re editing tests. You can create custom slash commands that your team uses every day. You can integrate MCP servers, so Claude Code has access to your internal tools, API schemas, and database documentation.

The certification tests whether you know when to use Claude Code’s plan mode (for complex changes with architectural implications) versus direct execution (for straightforward bug fixes). It tests whether you understand how to integrate Claude into your CI/CD pipeline so that pull requests are reviewed automatically before humans even see them.

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

Domain 4: Prompt Engineering & Structured Output (20%)

Every production system that uses Claude needs output it can trust. This domain covers techniques that actually reduce hallucination and improve reliability in real systems.

Few-shot examples work better than detailed instructions when you want consistent output. Using tools with JSON schemas eliminates syntax errors and enforces structure. Explicit criteria make the difference. This is a bug worth reporting; that is a style preference worth skipping. Both reduce false positives that erode trust.

The certification tests prompt patterns that solve real production problems. How do I make sure this extraction tool doesn’t hallucinate missing fields? How do I review 50 files consistently without contradicting myself from one file to the next?

Share Data Science In Action

Domain 5: Context Management & Reliability (15%)

When Claude has a lot of information to work with, it doesn’t retain all of it equally well. Information at the beginning and end of a prompt gets better attention than information in the middle. Large context windows don’t solve the attention problem. They create bigger middle sections.

This domain covers how to structure context so Claude doesn’t lose critical information (case facts, customer details) as context accumulates. It covers how to escalate intelligently. When to route a request to a human, when a policy gap means you should escalate versus when the agent can handle it.

It also covers multi-agent error handling: when one agent fails, how does that information flow back to the coordinator in a way that enables recovery instead of just stopping everything?

Leave a comment

Why These Five Matter

The certification isn’t about memorizing definitions. It’s about recognizing that these five domains represent decisions you make every time you ship something. The exam puts you in realistic scenarios. You’re building a customer support agent, designing an extraction pipeline, integrating Claude into CI/CD. Then it asks how you’d handle the tradeoffs.

If you’ve shipped production systems, you’ve already dealt with all five domains. You’ve probably struggled with at least three of them. This certification is about systematizing what you’ve learned through trial and error so that you can make those decisions faster and better next time.

The five domains map pretty cleanly onto the actual lifecycle of building a production Claude application — they’re not arbitrary categories; they’re sequential layers that depend on each other:

1. Agentic Architecture & Orchestration (27%) — the control flow layer
This is “how does the system decide what to do next”: loop mechanics (stop_reason), coordinator/subagent patterns, task decomposition, session management. It’s weighted most heavily because almost nothing else matters if the core loop and delegation logic are unreliable — a bad orchestration layer breaks everything downstream.

Give a gift subscription

2. Tool Design & MCP Integration (18%) — the interface layer
Once you have an agent that acts in a loop, it needs to act on something. This domain concerns how the model perceives and manipulates the outside world: tool descriptions, error schemas, and scoping tools per agent. It’s the natural next layer down from orchestration — orchestration decides when to call something, tool design determines whether the model calls the right thing and what happens when it fails.

Refer a friend

3. Claude Code Configuration & Workflows (20%) — the applied/dev-tooling instance
This is really domains 1 and 2 applied to a specific, extremely common product surface (Claude Code): CLAUDE.md hierarchies, skills, plan mode, CI/CD integration. It’s tested separately because it’s such a dominant real-world use case, but conceptually it’s “orchestration + tool design, specialized for developer workflows.”

Get a group subscription

4. Prompt Engineering & Structured Output (20%) — the reliability-of-output layer
Whereas 1–3 are about architecture, this domain is about getting a trustworthy answer from a single call or extraction: few-shot examples, JSON Schema enforcement, validation/retry loops, and batch processing. This matters independently of orchestration because even a single well-architected agent call can produce garbage without good prompt/schema design.

5. Context Management & Reliability (15%) — the cross-cutting constraint
This one is different in kind from the other four — it’s not a stage, it’s a constraint that touches all of them: context windows degrade orchestration (lost-in-the-middle), degrade tool outputs (verbose results crowding context), and degrade extraction (stale summaries causing hallucination). It’s weighted the least not because it’s least important, but because its content overlaps so heavily with the other four domains that much of it is implicitly tested there as well.

Why these five and not, say, “safety” or “model internals”?
Look at the out-of-scope list — training, RLHF, tokenization, auth, infra. The exam is explicitly scoped to architect-level system design decisions, not model internals or plumbing. The five domains cover the decision points a solutions architect actually owns: how the system loops, how it touches external systems, how it’s configured for teams, how it guarantees output quality, and how it survives long-running/multi-agent context pressure. Together they form one coherent story: build the loop → give it safe tools → configure it for a team → make its output trustworthy → keep it reliable as scale/context grows.

Subscribe to Data Science In Action to get more on Claude architecture, AI systems, and practical patterns that work in production.

#Claude #CertifiedArchitect #AI #ProductionSystems #Certification #BeginnerFriendly #DataScienceInAction

[Tutorial] Step-by-Step: Build Your Own Claude Writing Clone, With Templates

Engy Fouda — Tue, 11 Aug 2026 14:41:16 GMT

Quick context before we dive in: the AI Special Interest Group at the Harvard Club of New York City invited me to speak, and this tutorial, along with its companion free article, is part of how I’m organizing my thinking for that talk. If there’s a different angle on AI and writing you’d find more valuable to hear me cover, let me know. I’m still shaping the talk, and your input actually matters here.

Consider this your training session. If you have not read I’m Going to Train You to Clone Your Own Writing Voice With Claude, read that first for the seven-step overview. Below, I am walking you through every screen, every prompt, and every file, the same way I use it now.

What you need before we start

3 to 5 of your best published pieces
A Claude account with Projects access
About 45 minutes today, then a couple of minutes per piece afterward
Subscribe now

Step 1: Create your dedicated project

Do not fold this into an existing chat. Go to Projects, click Create project, and name it clearly.

Fill the description field honestly, this is the first thing Claude reads before your very first question in this Project.

How to Create Your Writing Clone Using Claude?

Engy Fouda — Thu, 06 Aug 2026 14:58:56 GMT

A quick note before we get into it: the AI Special Interest Group at the Harvard Club of New York City invited me to give a talk, and this article is my first pass at organizing the ideas I want to bring. Think of it as a working draft, I’m thinking out loud through, before it becomes a talk. If there’s a different angle on AI and writing you’d rather hear me speak on, tell me in the comments. I’d genuinely like to know what’s most useful to you.

Leave a comment

I built a Claude Project that writes in my exact voice, schedules itself, and publishes itself. I am not going to describe it to you from a distance. I am going to train you on it directly, the same way I would train a new hire, so you can build your own version this week.

1. Forget “write like me,” it is not an instruction

Telling Claude to sound casual, warm, or professional gives you a generic AI voice, the same voice every other newsletter is publishing right now. The model does not learn your voice from an adjective. It learns your voice from your actual sentences. So the first move is never a description; it is evidence: your own published work, fed in directly, with Claude asked to extract the patterns rather than guess at them.

Subscribe now

2. The seven-step system, in order

Here is the full framework I use, laid out step by step.

Figure 1: The seven-step framework flowchart

Figure 1: The full seven-step framework. Steps 1 through 4 are a one-time setup. Steps 5 and 6, testing and the drift check, are the ones you repeat for every single piece you write afterward. Step 6 is highlighted because it is the one people skip, and skipping it is exactly how a clone quietly stops sounding like you.

Read it top to bottom once before you touch Claude. Each box is a decision, not just an action, and I will walk through the reasoning behind each one in the paid tutorial.

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

3. Why can nobody copy this by stealing your prompt?

Can someone screenshot my custom instructions field?
It will not help them. The prompt is generic; it just points to four files. What makes the output unmistakably mine is what is inside those files, and those were built from my own published sentences. That is not copyable. That is the actual moat, and it is also why training you on this does not weaken what makes my own version work.

Share Data Science In Action

4. There is a second layer that most people never build

Once your project is written in your voice, the next question is what happens to that draft. Mine does not stop at drafting; it gets scheduled and published without me touching a keyboard twice.

Figure 2: The publishing pipeline flowchart

This is fully optional; you can absolutely stop at the drafting stage. But once your voice is reliable enough that you can trust it unattended, this removes the second job of manually posting everything yourself.

I am giving you the full build in the next paid tutorial, explaining every step and the exact prompts.

Want the whole thing without rebuilding it yourself?

I packaged this entire system, the seven-step process, every prompt, and four fill-in-the-blank templates, into a ready-to-use Claude skill. Drop it into any Claude Project, and it walks you through setup in order, no rebuilding from scratch required.

Grab the Writing Clone Builder skill →$39

#AITools #WritingWithAI #ClaudeAI #ContentCreation #Substack

Refer a friend

[Tutorial] How to Build Your First AI Loop in Claude Code in Step-by-Step with Screenshots

Engy Fouda — Tue, 04 Aug 2026 01:17:32 GMT

In the last article, I walked you through where loop engineering actually came from: Andrej Karpathy’s AutoResearch, an agent restricted to one file it could edit, one file it could never touch, and a rules file that set the boundaries in advance. Today, we build a loop with that same three-piece shape ourselves, just aimed at a much more familiar problem: a messy CSV.

What are we building?

A file called customers.csv with three problems: duplicate customer IDs, missing emails, and a few invalid signup dates. Our loop will keep fixing it, checking it, and fixing it again, until all three problems are gone, or until it hits a safety limit, the same keep-or-rollback shape Karpathy’s loop used on train.py.

But there’s a piece I glossed over the first time I wrote this tutorial, and it matters enough to fix properly: in Karpathy’s setup, the agent never grades its own work. A separate file, prepare.py, does that, and the agent isn’t allowed to touch it. Without that separation, an agent can quietly decide its own work passed, whether or not it actually did. So before we touch the CSV, we’re building that separation too, a standalone Python script called verify.py that checks the file and reports PASS or FAIL. The agent can run it. The agent cannot edit it.

Subscribe now

The four files:

customers.csv — the messy file. It has duplicate customer_id rows, a few blank emails, and a couple of invalid signup_date values. This is the only file the agent should edit.
verify.py — the evaluator. A plain Python script, no dependencies beyond the standard library, that checks the CSV and prints PASS or FAIL for each of the three rules. Exits with code 0 only if everything passes. The agent must never edit this file, that’s the whole point of it.
loop_rules.md — the guardrails: the goal (verify.py exits 0), the hard attempt limit, and the “never” rules, including the one that protects verify.py itself.
cleaning_log.md — not included yet. Claude Code will create this itself as the loop runs, since the rules ask it to log the verifier’s actual output on every attempt, not its own summary of how things went.
Share

How to run it

Put customers.csv, verify.py, and loop_rules.md in the same folder and open that folder in Claude Code.
Optional but worth doing: run python verify.py customers.csv yourself first, before the agent touches anything, so you’ve seen the baseline failure with your own eyes.
Start Claude Code and paste this prompt:

Read loop_rules.md and follow it exactly. Keep editing customers.csv until python verify.py customers.csv exits with code 0. After every attempt, run verify.py yourself and log its exact output, don’t judge success by reading the CSV. Stop after 5 attempts even if it’s still failing, and tell me exactly what verify.py still shows as FAIL.

Read the plan Claude Code gives you back before approving it. This is where you catch a bad assumption before it costs you five attempts.
Once it finishes, run python verify.py customers.csv yourself as a final check, don’t just trust the agent’s last log entry. Then open the cleaned CSV and cleaning_log.md and confirm the fixes are the ones you’d have made. The loop finishing without errors is a claim, not proof, and now you have an independent way to check that claim yourself.
Thanks for reading Data Science In Action! Share the article!
Share
You can download the files for this example from my website:

What Is Loop Engineering?

Engy Fouda — Fri, 31 Jul 2026 15:57:35 GMT

If you’ve spent any time working with Claude or another AI assistant, you know the rhythm. You type a prompt, you read the answer, you tweak your wording, you hit enter again. Prompt, read, tweak, repeat. It works, but you are the one doing the repeating. Loop engineering is the idea that you shouldn’t have to be.

In March 2026, Andrej Karpathy showed a different way, and it’s now got a name: loop engineering.

What does loop engineering actually mean?

Loop engineering is the practice of designing a system in which the AI continues to work on its own, in a repeating cycle, until a goal you defined is met. Instead of you prompting it ten times, you set it up once to prompt itself: try something, check the result, adjust, try again.

Karpathy put it plainly: the goal is to remove yourself as the bottleneck, put in very few tokens, and let a lot of work happen without you deciding the next step every time.

Give a gift subscription

Think of the difference between cooking on a stovetop and using a slow cooker. On the stovetop, you’re standing there, stirring, checking, adjusting the heat. With a slow cooker, you set the temperature and the time, and you walk away. It keeps working in its own loop: heat, wait, check, heat again, until dinner is actually done. You didn’t do the repeating. You designed the conditions.

That’s loop engineering: You’re not writing one prompt anymore. You’re designing the loop the AI runs inside of.

Subscribe now

Why is this different from prompt engineering?

Prompt engineering is about shaping a single input to yield a better single output. It’s the wording, the examples you give, the format you ask for.

Loop engineering happens one level up. It’s about what happens after the first response. Does the AI check its own work? Does it try again if something’s wrong? Does it know when to stop? A well-written prompt can still leave you babysitting the process. A well-designed loop doesn’t need you in the room.

A quick note on timing

This term is genuinely new. Karpathy released a small open-source project called AutoResearch: about 630 lines of code across three files. One file, train.py, is the only thing the agent is allowed to touch. A second file, prepare.py, scores the results and is off-limits, so the agent can’t just make the test easier instead of making the model better. A third file, program.md, holds the rules and constraints a human wrote in advance.

The loop itself is simple: the agent reads the code, proposes a change, trains it for a few minutes, keeps the change if it improved things, rolls it back if it didn’t, and repeats. Karpathy wasn’t running each experiment by hand anymore. He’d removed himself from the middle of the process and let the loop run.

The project went viral within days. People started calling the pattern the “Karpathy Loop.” A few months later, the wider builder community coined the term “loop engineering” to describe that same shift more generally. It has since picked up momentum in June 2026, with Addy Osmani writing about it. Both Boris Cherny at Anthropic and Peter Steinberger describe a real shift in how they work with coding agents: designing the system that prompts the agent, rather than prompting it turn by turn. If this is the first time you’re hearing it, you’re not behind. You’re right on time.

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

The five pieces of a real loop

Every loop worth building has these parts, and if any one of them is missing, the loop either does nothing useful or never stops:

A goal. Not “clean up this data,” but something specific enough to check: “no null values in the email column, no duplicate IDs.”
An action. What the AI actually does on each attempt: edit a file, run a query, fix a bug.
An observation. How does it check whether the action worked? Did the test pass? Does the data now meet the rule?
An adjustment. If it didn’t work, try it differently next time, not just the same thing again.
A stopping point. A hard limit on attempts, and clear instructions for what to do if it hits that limit without succeeding.
Share Data Science In Action

That last one matters more than people expect. A loop without a stopping point isn’t autonomous; it’s just expensive. It’ll keep running, keep using tokens, and keep making changes to your files, possibly getting further from a working answer with every attempt instead of closer.

Let me elaborate using Karpathy’s AutoResearch, which actually maps cleanly onto this, so I’ll use his three files as the example alongside the general pattern:

A goal. In AutoResearch, this lives in program.md, the constraints a human wrote before the loop ever ran. For your own loop, this needs to be specific enough to check: not “clean up this data,” but “no null values in the email column, no duplicate IDs.”
An action. What the AI actually does on each attempt. In AutoResearch, that’s editing train.py, and only train.py.
An observation. How it checks whether the action worked. In AutoResearch, that’s prepare.py, a separate evaluator that the agent can’t touch or game.
An adjustment. If it didn’t work, what it tries differently next time, not just the same thing again. Karpathy’s loop keeps the change if it improved things and rolls it back if it didn’t.
A stopping point. A hard limit on attempts, and clear instructions for what to do if it hits that limit without succeeding.

Have you already seen this without the name?

If you’ve read my article on understanding Claude Hooks, you’ve already seen a piece of this. Hooks are the deterministic guardrails that fire at key moments, automatically formatting code and blocking dangerous commands. In a loop, those same guardrails are what keep the cycle from wandering off and doing something you didn’t ask for.

And if you’ve read Building Your Own Agentic AI System, you already know that agentic AI is defined by a control loop, the part of the system that lets it plan, act, and adjust across multiple steps instead of answering once. Loop engineering is the practice of deliberately designing the control loop, rather than letting it happen by accident.

One honest caution before you get excited

A loop that runs on its own can also make mistakes when left unattended. The whole point of building in checks is to make “done” actually mean something, not just to make the AI feel busy. When a loop runs smoothly, it’s tempting to stop paying attention and just accept whatever comes out the other side. Don’t. Your job is still to read what the loop produced and confirm it actually works before you trust it.

Loop engineering doesn’t remove you from the process. It changes your job from typing every step to designing the system and checking its work, exactly the trade Karpathy made when he stopped running his own experiments by hand.

In the paid tutorial, I’ll walk you through building your first real loop in Claude Code, step by step, with screenshots at every stage, using the same three-piece structure Karpathy used, a goal, an action the agent can take, and a separate check it can’t game, applied to a task you’ll actually recognize: cleaning a messy CSV file until it passes real data quality checks.

Refer a friend

What’s the most repetitive part of your AI workflow right now, the part where you keep typing basically the same follow-up over and over? Tell me in the comments, it might be exactly the kind of task a loop can take off your plate.

Leave a comment

[Tutorial] Skills, Workflows, and Agents: A Hands-On Tutorial Using Claude Chat & Cowork

Engy Fouda — Wed, 29 Jul 2026 22:06:37 GMT

In the free article last week, I explained what skills, workflows, agents, and frameworks are and how they’re different. If you haven’t read that one yet, start there:

In this tutorial, I’ll show you what each one looks like in practice using Claude Cowork and Claude chat. No coding. No Claude Code. No API costs on top of your subscription.

This matters more than it sounds. Claude Code is a fantastic tool, but it’s built for developers, and it can rack up API charges beyond your monthly plan, billed per use. If you’re job hunting, repurposing content, or organizing meeting notes, you don’t need that overhead. Everything in this tutorial runs inside what you’re already paying for.

Subscribe now

What You’ll Need

Claude Pro (or any plan with Cowork access)
Claude Cowork, open with a new project
No prior experience needed. If you can type a sentence, you can do this.
Data Science In Action is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Step 1: Build a Meeting Summary Skill

A skill in Cowork is a reusable set of instructions you save once and reuse anytime. Let’s build one that turns messy meeting notes into a clean summary with action items.

Open Cowork, start a new project, and say:

“Create a skill called ‘meeting-summary’. This skill should read any meeting notes I give it, whether typed, pasted, or uploaded, and produce: a 3-4 sentence summary of what was discussed, a numbered list of action items with who owns each one if mentioned, and a list of any deadlines mentioned, called out clearly. Keep the tone plain and professional. Do not add opinions or invent details that weren’t in the notes.”

That’s it. No file structure to build by hand, no folders. Cowork saves this as a reusable skill you can call on anytime.

Now test it. Paste in some rough notes:

“Use the meeting-summary skill on this: Discussed Q3 goals. Budget approval needed by Friday. Team to review new onboarding doc. Follow up with Sarah on marketing plan.”

That’s a skill in action. One task, clearly defined, reusable every time you have notes to clean up. You didn’t write a line of code, and you didn’t touch anything outside your normal Claude subscription.

If you want to see what more advanced skills look like once you’re comfortable, Anthropic maintains an open library you can browse for inspiration: github.com/anthropics/skills. You won’t need to build anything that complex for most day-to-day tasks, but it’s worth a look.

Step 2: Build a Job Hunting Workflow

A workflow is a fixed sequence of steps that always runs in the same order. Let’s build one for job hunting: from job posting to a tailored application, every time, no coding required.

In the same Cowork project, say:

“Create a workflow called ‘job-application-prep’. Every time I give you a job posting and my current resume bullets, follow these steps in order:
1) List the top 5 requirements the posting emphasizes most.
2) Rewrite one of my resume bullets so it speaks directly to this posting’s language, without inventing experience I don’t have.
3) Write a 2-3 sentence cover letter opening that connects my background to this specific role and mentions the company by name.
4) Format one row for my application tracker with columns: Company, Role, Date Applied, Key Requirement Matched, Status. Always complete all four steps in order, don’t skip any.”

Now run it:

“Run job-application-prep. Posting: [paste any real job posting].
My resume bullets: [paste 2-3 of your current bullets].”

Notice what the workflow does NOT do. It doesn’t decide the job is a bad fit and stop early. It doesn’t skip the cover letter step because your resume already looks strong. It runs the same four steps every time, in the same order.

That predictability is exactly the point. When you’re applying to a dozen jobs a week, you want consistency, not surprises, and you want it without paying per API call for the privilege.

Share Data Science In Action

Step 3: Build a Content Repurposing Agent

The Architect's Guide to AI Skills, Workflows, AI Agents, and AI Framework

Engy Fouda — Tue, 21 Jul 2026 19:34:17 GMT

AI has a vocabulary problem. Everyone is talking about agents, workflows, skills, and frameworks. And if you are just getting started, those four words can feel like the same thing said four different ways.

They are not. Each one solves a different problem at a different level. Once you understand the difference, you will start seeing them everywhere and know exactly which one to reach for.

Let me walk you through each one.

The kitchen analogy

Before I throw definitions at you, let me give you a picture that makes all four click at once.

Imagine a restaurant kitchen.

A skill is a recipe card. It tells the cook exactly how to make one dish, step by step.

A workflow is the prep schedule. It sequences the recipe cards in the right order so dinner service runs smoothly.

An agent is the head chef. They know the recipes, they follow the schedule, but they can also improvise when something goes wrong, or a customer asks for something off-menu.

A framework is the kitchen infrastructure itself: the stations, the ticketing system, the shared rules that let every cook and chef work together without stepping on each other.

Keep that image in mind. Let us go deeper.

Subscribe now

What is a skill?

A skill is a single, well-defined capability that an AI can perform.

It does one thing. It does it reliably. It is reusable.

Examples of skills:

Summarize a document
Draft an email reply
Format a table
Search the web for a topic
Translate text

A skill is not a process. It is not a decision. It is a tool in a toolbox.

In Claude Cowork, for example, a skill is a small instruction file that teaches Claude exactly how to produce one specific output: a Word document, a PowerPoint slide, or a PDF. The skill gets called when you need that output and nothing else.

Pros of skills:

Simple to build and maintain
Easy to reuse across different tasks
Fast to execute
Easy to test (one input, one expected output)

Cons of skills:

Limited in scope by design
Cannot adapt to unexpected situations
Needs something else to coordinate it with other skills
Thanks for reading Data Science In Action! This post is public, so feel free to share it.
Share

What is a Workflow?

A workflow is a sequence of steps that happen in a specific order to accomplish a larger goal.

Where a skill does one thing, a workflow chains multiple things together, it is the “first do this, then do that, then check if it worked” layer.

Workflows are great when:

The process is predictable and repeatable
The same steps happen every time
You want to automate something you currently do manually

A real example: every Monday morning, you want to check your unread emails, pull out the action items, create a task list, and draft a summary for your team. That is a workflow. Each part (checking email, extracting action items, formatting a list, drafting a summary) might be a separate skill. The workflow stitches them together in the right order.

If you have read my article on agentic workflows, you already have a head start here: Agentic Workflows for Beginners.

Pros of workflows:

Predictable and transparent (you know exactly what will happen)
Easy to automate and schedule
Great for repeatable business processes
Easier to debug than an agent (you can check each step)

Cons of workflows:

Rigid: if the process changes, you have to update the workflow
Not great at handling exceptions or surprises
Needs someone to design the steps upfront
Share

What is an AI Agent?

An AI agent is a system that can perceive its environment, make decisions, use tools, and take actions, all in pursuit of a goal.

This is where it gets exciting, and a little more complex.

Unlike a workflow, an agent does not just follow a fixed sequence. It determines the steps to take based on what it discovers along the way. It can loop, backtrack, try different approaches, and decide when it is done.

Think about Claude Code. You give it a goal: “Refactor this code to be cleaner.” Claude Code does not follow a preset checklist. It reads the code, decides what needs to change, makes the changes, checks the result, and adjusts. That is an agent.

Agents are the right choice when:

The path to the goal is not fully predictable
You need the AI to make judgment calls
The task has many possible routes to the same outcome

Pros of agents:

Flexible and adaptive
Can handle complex, open-ended tasks
Can use multiple skills and tools dynamically

Cons of agents:

Less predictable than workflows
Harder to debug (”why did it do that?”)
Can be slower and more expensive to run
May need guardrails to stay on track
Share Data Science In Action

What is an AI Framework?

A framework is the infrastructure layer that helps you build, connect, and run agents, workflows, and skills at scale.

If skills are recipe cards, workflows are schedules, and agents are chefs, a framework is the kitchen design itself: the layout, the communication system, the shared standards that let everything work together.

Examples of AI frameworks:

LangChain: helps you build pipelines and chains of AI calls with tools and memory
LlamaIndex: specializes in connecting AI to your data (documents, databases)
AutoGen: helps you build multi-agent systems where multiple AI agents collaborate
Claude Agent SDK: Anthropic’s own toolkit for building agents that use Claude

You typically reach for a framework when you are building something that needs to scale, involve multiple agents working together, or run repeatedly in a production environment.

Pros of frameworks:

Reusable patterns and components
Saves you from rebuilding common functionality
Designed for production use
Often includes memory, tool use, and orchestration built in

Cons of frameworks:

Steeper learning curve
Overkill for simple tasks
Adds complexity and dependencies
You need to understand the framework, not just the AI
Refer a friend

The Decision Guide

Here is how I think about which one to use:

More simply: start with the simplest thing that works.

If one prompt and one output solve your problem, you do not need a workflow. If a workflow handles it, you do not need an agent. If you are building one thing for yourself, you probably do not need a framework.

The temptation is always to build the most sophisticated thing. Resist it. Complexity is something you add only when you have run out of simpler options.

Subscribe now

How do they fit together?

Here is the important part: these are not competing options. They are layers.

A framework runs agents. An agent executes workflows. A workflow calls skills.

You might build a research agent using the Claude Agent SDK (framework), which follows a research process (workflow) and uses individual tools like “search the web” and “summarize a page” (skills).

That is the full stack. And once you see it that way, the whole thing becomes much less intimidating.

What comes next?

In the paid article this week, I walk you step by step through building each one: a skill, a workflow, and an agent, using tools you may already have. I show you what each one looks like in practice and when the difference becomes obvious.

For now, try this: think about one thing you do repeatedly that takes more than 10 minutes. Is it one task (skill)? A sequence (workflow)? Or does it require judgment calls (agent)?

Drop your answer in the comments. I would love to hear what you are trying to automate.

Leave a comment

[Tutorial] How to Build a Personal AI Governance Checklist Using Claude?

Engy Fouda — Thu, 16 Jul 2026 18:14:36 GMT

In the free article this week, I explained what AI governance is and how it differs from guardrails, harnesses, and safety research. If you haven’t read it yet, go there first: it gives you the foundation for everything we’re doing here.

Now let’s make it real.

In this tutorial, you will build a personal AI governance checklist using Claude. This is a structured template you can use before deploying any AI workflow, prompt, or automation. Think of it as your pre-flight checklist: something you run through every time, so that important questions don’t fall through the cracks.

By the end, you will have:

A working governance checklist document
A Claude prompt you can reuse to generate project-specific checklists
A review workflow you can run in Claude.ai

Let’s go.

Subscribe now

What We’re Building?

We’re going to use Claude.ai to create a governance checklist generator. You’ll give Claude a description of any AI project, and it will produce a tailored checklist covering accountability, transparency, fairness, privacy, safety, and human oversight, the six pillars we covered in the free article.

You’ll also save a reusable prompt so you can regenerate this for any future project in seconds.

Tools you need:

A free or paid Claude.ai account
A text editor (Notepad, Word, Google Docs, anything works)
20 minutes

Step 1: Open Claude.ai and Start a New Chat

Go to claude.ai and log in. Click the “New Chat” button in the top left corner.

You should see a clean, empty chat window. This is where we’ll work.

Step 2: Give Claude the Context for Your Project

Before we generate the checklist, we need to tell Claude what kind of AI project we’re reviewing. The more specific you are, the more useful the output will be.

For this tutorial, let’s use a realistic example: a simple Claude-powered customer service chatbot that answers questions about a company’s return policy.

Paste this into the chat exactly as written:

What Is AI Governance?

Engy Fouda — Tue, 14 Jul 2026 17:45:16 GMT

If you’ve been following AI news lately, you’ve probably seen “AI governance” pop up in headlines. The EU AI Act. Executive orders. Companies are publishing their “responsible AI principles.” It sounds like something for lawyers and regulators, not for someone who’s just learning data science or building AI tools.

But here’s what I’ve come to realize after working in this space: AI governance is not just a policy topic. It’s a practical one. And the sooner you understand what it actually means, the better decisions you’ll make as someone who builds with, uses, or recommends AI systems.

Let’s break it down, with no jargon left unexplained.

What AI Governance Actually Means?

AI governance is the set of rules, processes, and accountability structures that decide how AI is developed, deployed, and used, and by whom, and for what purposes.

Think of it like this: imagine a city with no traffic laws. Cars can go wherever they want, as fast as they want. That’s efficient until it isn’t. People get hurt. Trust breaks down. Governance is the traffic system: the lights, the speed limits, the lanes, the rules for who has the right of way.

AI governance works the same way. It asks questions like:

Who is responsible when an AI system makes a harmful decision?
What data is allowed to train a model, and what’s off limits?
How do we make sure an AI system treats all users fairly, regardless of their background?
How do we audit whether an AI system is doing what we say it’s doing?
What happens when something goes wrong?

These aren’t abstract philosophical questions. They’re design decisions that affect real people.

Subscribe now

Why This Is Relevant to You Right Now?

You might be thinking: I’m just learning Python. Or I’m just using Claude for work. Why does governance apply to me?

It applies because AI is no longer something that only researchers and tech companies build. You are building with it. When you design a prompt that filters job candidates, or build an AI assistant that answers customer questions, or automate a reporting workflow that your manager trusts, you are making governance decisions whether you realize it or not.

What data are you feeding the model? Who sees the outputs? What happens if the model gets it wrong? Those questions don’t disappear just because you didn’t write them down. Governance is the practice of making decisions intentionally, not by accident.

The Key Pillars of AI Governance

Let’s walk through the main things that AI governance actually covers. Think of these as the building blocks.

1. Accountability

Someone has to be responsible when an AI system fails.

Governance frameworks define who that is: the developer who built the model? The company that deployed it? The user who ran it?

Clear accountability means someone is watching and someone answers for the outcomes.

I always show my machine learning students this video to provoke them to think about the implications of what their models are, to demonstrate what AI governance is, and how crucial it is to be cautious with contracts’ liability terms:

Thanks for reading Data Science In Action! This post is public, so feel free to share it.

2. Transparency

Can you explain how the AI reached its decision?

A model that says “loan denied” without any explanation is very different from one that says “loan denied because the income-to-debt ratio exceeded our threshold.” Transparency is about making AI decisions understandable and auditable.

I use this exact business problem to teach my students how some machine learning models are easier to visualize their decisions than others, and to communicate the business decision. For this example, I demonstrate how decision tree and random forest models are easier to explain than others.

Share Data Science In Action

3. Fairness

Does the system treat different groups of people equitably?

An AI system trained on biased data will produce biased outputs, even if no one intended that. Fairness in governance means actively testing for and correcting those disparities.

For this concept, I usually use the Students for Fair Admissions v. Harvard legal case. https://en.wikipedia.org/wiki/Students_for_Fair_Admissions_v._Harvard

Refer a friend

4. Privacy

What data does the model use, and is it protected appropriately?

This pillar covers everything from GDPR compliance to ensuring a customer’s private health records aren’t inadvertently leaked into model training data.

Leave a comment

5. Safety and Reliability

Does the system behave safely, especially in edge cases?

Governance here means defining what happens when the model is uncertain, when inputs are unusual, or when the stakes are high.

6. Human Oversight

Who can override, correct, or shut down the AI system?

Governance ensures there’s always a human in the loop for decisions that matter, especially high-stakes ones.

Wait, Is This the Same as Guardrails? Or Harnesses? Or Safety?

This is where beginners get confused, and honestly, the terminology doesn’t help. Let me sort it out for you.

These terms often get used interchangeably, but they live at very different levels of your stack.

Guardrails are the technical controls you build around a model to constrain its behavior. They’re code-level interventions: input filters, output validators, toxicity detectors, prompt injection blockers. If the model starts generating something harmful, a guardrail catches it and stops it, redirects it, or flags it.

I wrote a full breakdown of guardrails in a previous article: if you haven’t read it yet, start there before going deeper on governance: A Practical Guide to AI Guardrails.

Harness (or sometimes “evaluation harness”) refers to the testing and benchmarking infrastructure you use to measure how well a model performs. It’s your test suite for AI. You run the model through thousands of scenarios and measure accuracy, safety, consistency, and quality. It’s a quality assurance tool, not a runtime control.

AI Safety is the research field that asks: can we build AI systems that reliably do what humans intend, even as they become more capable? It’s a broader, often more theoretical discipline that governance draws on, but safety research and governance practice are not the same thing.

AI Governance sits above all of these. It’s the framework that decides: what guardrails do we require? Who runs the harness evaluations, and how often? What does “safe enough to deploy” actually mean for our organization? Governance is the policy and process layer. The others are the tools that governance directs.

A quick way to remember the difference:

Guardrails: the fence on the road
Harness: the test drive before launch
Safety research: the science of how to build better roads
Governance: the law that decides where roads can go, who can drive them, and what happens after an accident

You need all of them. But they are not the same thing.

Give a gift subscription

What Good AI Governance Looks Like in Practice

Governance isn’t just a document on a shelf. When it’s actually working, it shows up in concrete ways:

A company publishes its AI use policy and updates it when the technology changes
A team runs regular bias audits on their models before shipping updates
There’s a clear escalation path when a user reports that the AI behaved unexpectedly
AI outputs in high-stakes contexts (medical, financial, legal) always have a human review step
There’s a log of which version of a model made which decision, so that you can trace back errors

None of that happens automatically. It has to be designed, resourced, and enforced.

Subscribe now

Where to Start as a Beginner?

You don’t need to read 400 pages of the EU AI Act to start thinking about governance. Here are three practical habits that will make you a more responsible AI practitioner from day one:

Document your assumptions. When you build a prompt or a workflow, write down what you assume the model will and won’t do. That documentation is the beginning of accountability.

I learned the importance of documentation the hard way. I have plenty of examples from my and my friends’ experiences about that. I can’t emphasize the importance of documentation enough. I always say that I’m a documentation fanatic because documentation can literally save you from prison!

Documentation can save your life from prison! Don’t neglect it!

Test your outputs with edge cases. Don’t just check if the happy path works. What happens when someone inputs something unexpected? What happens when the data is missing or wrong?
Know who the AI decisions affect. Before deploying any AI tool, ask yourself: whose life or work does this touch? And what’s the worst case if it gets it wrong?

Governance starts small. It starts with you asking the right questions before you ship.

In this week's paid tutorial, I walk you through, step by step, how to set up a simple AI governance checklist for your own AI projects using Claude. You’ll end up with a reusable template you can apply to anything you build.

If you want the full tutorial, upgrade to a paid subscription below.

Subscribe now

#AIGovernance #DataScience #ResponsibleAI #BeginnerFriendly #DataScienceInAction

[Tutorial] API vs MCP

Engy Fouda — Mon, 13 Jul 2026 20:49:23 GMT

What is the difference between API and MCP?

MCP and APIs both let software interact with other systems, but they serve very different purposes:

APIs are built for developers
MCP is built for AI models.

MCP exists because AI models cannot reliably use APIs on their own.

API (Application Programming Interface)

A set of rules that lets software talk to software.
Designed for developers to request data or trigger actions.
Requires explicit coding: endpoints, authentication, error handling, etc.
Example:

GET https://api.github.com/users/username

This returns structured JSON.

MCP (Model Context Protocol)

A protocol designed so AI models can safely interact with tools, data, and systems.
AI models cannot make real network requests or handle tokens, headers, or API formats.
MCP exposes “tools” with schemas that define the model’s inputs and outputs.
Acts as a bridge between an AI model and the real world.

Subscribe now

When to Use Which

Use APIs when:

You’re building software integrations
You need predictable, stable, repeatable workflows
A human developer is writing the logic

Use MCP when:

You want an AI model to interact with your systems
You need dynamic, model-driven workflows
You want strict control over what the model can do
Share Data Science In Action

PROJECT: Currency Converter

Let’s build a clean, real‑world example, perfect for learning both workflows, a currency conversion project:

Using a normal API key in Python
Wrapping the same functionality in an MCP server

We’ll build:

Part A: A Python script that uses an API key to convert USD → EUR
Part B: An MCP server that exposes a tool called convertCurrency. So an AI model can do the same conversion safely

Everything is step‑by‑step and runnable.

Refer a friend

PART 1: Using a Currency API Directly

We’ll use ExchangeRate‑API, which has a free tier and simple keys.

Step 1.1: Create an account and get your API key

Go to the ExchangeRate‑API website
Click Sign Up
Create an account
Go to your Dashboard → API Keys
Copy your key

pip install requests

Step 1.3: Create a Python script

Create a new Python notebook and paste in the following code:

import requests

API_KEY = "YOUR_EXCHANGE_RATE_API_KEY"

def convert_currency(amount, from_currency, to_currency):
    url = f"https://v6.exchangerate-api.com/v6/{API_KEY}/latest/{from_currency}"

    response = requests.get(url)
    response.raise_for_status()

    data = response.json()
    rate = data["conversion_rates"][to_currency]

    return amount * rate

if __name__ == "__main__":
    result = convert_currency(100, "USD", "EUR")
    print(f"100 USD is {result:.2f} EUR")

After you run it, here is the output for the time of writing this article:

PART 2: Using MCP

Now, we’ll expose the same conversion logic as an MCP tool called convertCurrency.

This is the workflow where:

The model calls the tool
The MCP server calls the real API
The API key stays hidden

For this example, I’ll use www.kaggle.com to avoid the hassle of installing Python for anyone who doesn’t have it installed on their machines. I always vouch for using Kaggle to my newbie students because it is more than an online Python and R playground. It is a community offering free learning courses and cloud sandboxes, another way to build your portfolio beyond GitHub to demonstrate your experience with real-world data and projects, and another way, beyond LinkedIn, to build your networking in data science and machine learning online. Moreover, you can use it as a side gig and generate some money by competing.

The code explanation is below the code steps. Continue Reading :)

Step 2.1: Install the MCP server library

pip install mcp-server requests

If you are using Kaggle notebooks, add an exclamation mark at the beginning, as follows:

!pip install mcp-server requests

The output is as follows:

Leave a comment

Step 2.2: Write the MCP server

Paste this code after substituting the EXCHANGE_RATE_API_KEY that is written in the code with the one you generated in step 1.1.

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

# Set your Exchange Rate API key (https://www.exchangerate-api.com/)
#substitute here with your API Key
os.environ["EXCHANGE_RATE_API_KEY"] = "EXCHANGE_RATE_API_KEY"
API_KEY = os.getenv("EXCHANGE_RATE_API_KEY")

# Create the MCP server
server = FastMCP("currency-converter")

# Register the tool using the FastMCP decorator (this is the modern MCP SDK API)
@server.tool()
def convert_currency(amount: float, from_currency: str, to_currency: str) -> dict:
    """Convert an amount from one currency to another using live exchange rates."""
    url = f"https://v6.exchangerate-api.com/v6/{API_KEY}/latest/{from_currency}"
    response = requests.get(url)
    response.raise_for_status()
    data = response.json()
    rate = data["conversion_rates"][to_currency]
    return {
        "amount": amount,
        "from": from_currency,
        "to": to_currency,
        "converted_amount": amount * rate,
        "rate": rate
    }

# Test the tool directly (Kaggle-friendly - no need to run the full MCP server event loop)
result = convert_currency(amount=100, from_currency="USD", to_currency="EUR")
result

Step 2.3 — What the AI model sees

The model sees only the tool interface:

{
  "name": "convertCurrency",
  "description": "Convert an amount between two currencies",
  "inputSchema": {
    "type": "object",
    "properties": {
      "amount": { "type": "number" },
      "from_currency": { "type": "string" },
      "to_currency": { "type": "string" }
    },
    "required": ["amount", "from_currency", "to_currency"]
  }
}

When the user says:

Convert 100 USD to JPY

The model calls:

{
  "tool": "convertCurrency",
  "arguments": {
    "amount": 250,
    "from_currency": "USD",
    "to_currency": "JPY"
  }
}

The MCP server does the real API call and returns structured data.

The output looks like this:

Code Walkthrough for Beginners

Let’s break down what this code is actually doing, piece by piece, so it makes sense even if you have never touched MCP before:

The imports: os and requests do the same job as in Part 1, requests talks to the currency API, and os lets us read the API key from an environment variable. The new piece is “from mcp.server.fastmcp import FastMCP”, which imports the class that converts an ordinary Python function into something an AI model can call.
Setting the API key: os.environ[“EXCHANGE_RATE_API_KEY”] = “…” stores your key as an environment variable, then API_KEY = os.getenv(“EXCHANGE_RATE_API_KEY”) reads it back into a normal variable. Keeping the key in a variable like this means you only type it once, and it is the same key you got in Step 1.1.
Creating the server: server = FastMCP(“currency-converter”) creates the MCP server and gives it a name. Think of this server as the “middleman” that will sit between an AI model and your Python code.
The @server.tool() decorator: this single line just above the function is what actually turns a normal Python function into an MCP tool. Once decorated, the server automatically shares the function’s name, its docstring, and its parameter types with any AI model that connects, so the model knows the tool exists and how to use it.
The function itself: convert_currency(amount, from_currency, to_currency) works exactly like the plain API version from Part 1. It builds the request URL, calls the API, and reads the exchange rate. The one difference is what it returns: instead of a single number, it returns a dictionary with several fields (amount, from, to, converted_amount, rate), so the model gets back rich, structured data instead of a raw value.
The test call at the bottom: result = convert_currency(amount=100, from_currency=”USD”, to_currency=”EUR”) simply calls the function directly, the same way you would call any Python function. This lets you check that the tool works correctly before ever connecting it to a real AI model or running the full MCP server.

One important thing to note: in this example, we call convert_currency() directly to prove the logic works. In a real deployment, an AI model would never call the Python function itself. Instead, it would send a request to the MCP server, which would run the function on the model’s behalf, as described in Step 2.3.

Final Comparison

Start writing today. Use the button below to create a Substack of your own

Start a Substack