# Designing a custom AI agent for repetitive QA workflows

DevFeed: [Designing a custom AI agent for repetitive QA workflows](<https://devfeed.tech/articles/designing-a-custom-ai-agent-for-repetitive-qa-workflows-22591.md>)

Original publisher: [Read original article](<https://medium.com/amex-gbt-technology/designing-a-custom-ai-agent-for-repetitive-qa-workflows-6dcce6f9de10?source=rss----60a0578f4096---4>)

Author: Rimple Sharma

Published: 2026-05-18T06:01:01Z

Content type: tutorial

Language: en

Sources: [Amex GBT Technology](<https://devfeed.tech/sources/amex-gbt-technology.md>)

Topics: [AI Agent](<https://devfeed.tech/topics/ai-agent.md>), [Markdown](<https://devfeed.tech/topics/markdown.md>), [Parser](<https://devfeed.tech/topics/parser.md>), [context](<https://devfeed.tech/topics/context.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [ai-agent](<https://devfeed.tech/tags/ai-agent.md>), [ai-skills](<https://devfeed.tech/tags/ai-skills.md>), [context](<https://devfeed.tech/tags/context.md>), [markdown](<https://devfeed.tech/tags/markdown.md>), [parsing](<https://devfeed.tech/tags/parsing.md>), [software-testing](<https://devfeed.tech/tags/software-testing.md>), [test-automation](<https://devfeed.tech/tags/test-automation.md>)

## AI overview

This tutorial explains how to design a custom AI agent for repetitive QA workflows. It focuses on encoding structured instructions in Markdown, including headers, rules, variables, examples, output schemas, and executable commands, and introduces the agent's processing loop.

## Source excerpt

Part 2: Markdown as agent logic and the ReAct loop in action. In Part 1, I walked through the problem, repetitive QA work that resists pure scripting and the three pillars of a useful agent: input validation, context awareness, and a decision engine. I also showed why structured instructions beat plain text. This part is about how that structure gets encoded, how the loop runs, and what the impact looked like in practice. Why agents use Markdown When writing instructions for an agent, Markdown isn't just a formatting choice, it acts as a bridge between human-readable text and machine-processable logic. It's become a common format for agent communication because both humans and machines can work with it efficiently. But what most people miss... When you write agent instructions in Markdown, you're creating a weighted logic map, as well as just writing text. A few patterns that matter: 1. Semantic headers (#, ##) act as anchors for the agent's attention. Wrapping your mandatory rules under a clear header makes it far less likely the agent will overlook them mid-task. 2. Horizontal rules ( -- -) separate identity from instructions. Without this boundary, rules from one section bleed into another and the agent loses track of what governs what. 3. Bold keywords (**NEVER**, **ALWAYS**, **MANDATORY**) tend to be treated as hard constraints. Bold is a hard constraint. Italics are treated as a soft suggestion. 4. Blockquotes (>) are useful for examples. Wrapping an example in a blockquote signals to the agent that this is a reference, not a direct command. 5. {{curly_braces}} mark dynamic variables. They tell the agent that this part of the input will be filled in at runtime -- things like {{TICKET_ID}} or {{DATASET_NAME}} -- so it never substitutes a generic placeholder into a production file. 6. Fenced code blocks define output schemas. If you want the agent to always respond in a specific format, put that format in a code block. It treats it as a contract. 7. Inline code signa