AI agent architectures, tool calling and ReAct loops

Design a customer support agent that can look up order information, process refunds, and escalate to humans. Define the necessary tools and the agentic loop.

Step 1: Define the tools the agent needs.
- lookup_order(order_id: str) → Returns order details, status, items, and history.
- process_refund(order_id: str, amount: float, reason: str) → Initiates refund, returns confirmation or error.
- create_ticket(user_id: str, issue_summary: str, priority: str) → Creates escalation ticket, returns ticket ID.
- check_inventory(product_id: str) → Checks if replacement item is available.

Step 2: Define the agent loop (ReAct pattern).
1. Receive user query with authentication context (user_id).
2. THOUGHT: Analyze the query to determine intent and required information.
3. ACTION: Call appropriate tool(s) based on intent.
4. OBSERVATION: Receive tool output.
5. THOUGHT: Evaluate if the result satisfies the user's need or if more actions are needed.
6. If task complete: Respond to user with summary.
7. If stuck after 3 iterations: Escalate to human using create_ticket.

Step 3: Add guardrails.
- Require order_id verification before processing refunds.
- Limit refund amount without supervisor approval (e.g., 500 USD threshold).
- Log all actions for audit trail.
- Maximum 10 tool calls per conversation to prevent runaway loops.

A research agent needs to answer questions by searching the web and synthesizing findings. Implement a multi-hop retrieval pattern where the agent can follow citations.

Step 1: Define the tools.
- web_search(query: str) → Returns top search results with URLs and snippets.
- fetch_page(url: str) → Returns full text content of a webpage.
- extract_citations(text: str) → Returns URLs referenced in the text.

Step 2: Implement the multi-hop retrieval loop.
1. Initial query: User asks 'What are the latest advances in quantum error correction?'
2. ACTION: web_search('latest advances quantum error correction 2025')
3. OBSERVATION: Results include academic papers, news articles, and blog posts.
4. THOUGHT: The top result from Nature looks most authoritative. Let me read it.
5. ACTION: fetch_page(nature_article_url)
6. OBSERVATION: Article discusses new surface code implementations and cites relevant papers.
7. THOUGHT: This paper cites the original surface code paper-I should read that for context.
8. ACTION: extract_citations(current_text) → Returns URLs including the foundational paper.
9. ACTION: fetch_page(foundational_paper_url)
10. OBSERVATION: Explains the theoretical basis for surface codes.
11. THOUGHT: Now I have enough context to synthesize a comprehensive answer.
12. OUTPUT: Summarize findings with citations to both sources.

Step 3: Add stopping conditions.
- Maximum 5 hops to prevent infinite citation chasing.
- Track visited URLs to avoid re-fetching.
- Use embedding similarity to assess when gathered information is sufficient.

Design a multi-agent code review system where one agent writes code, another reviews it, and a third runs tests. Implement the orchestration pattern.

Step 1: Define agent roles.
- Coder Agent: Receives specifications, generates code, can iterate based on feedback.
- Reviewer Agent: Analyzes code for bugs, security issues, and style violations.
- Tester Agent: Runs test suites, reports failures, suggests fixes.
- Orchestrator Agent: Coordinates the workflow, tracks progress, makes final decisions.

Step 2: Define the orchestration workflow.
1. Orchestrator receives task: 'Implement a user authentication module.'
2. Orchestrator creates a plan: code → review → test → fix → review → test.
3. Orchestrator sends specification to Coder.
4. Coder generates code and returns to Orchestrator.
5. Orchestrator sends code to Reviewer.
6. Reviewer analyzes and returns: 'Found potential SQL injection in line 45, missing input validation.'
7. Orchestrator sends issues to Coder with instructions to fix.
8. Coder fixes issues and returns updated code.
9. Orchestrator sends code to Tester.
10. Tester runs tests and returns: 'All tests pass except edge case for empty passwords.'
11. Orchestrator sends test failure to Coder.
12. Coder fixes edge case.
13. Orchestrator re-runs review and test cycle.
14. When all checks pass, Orchestrator outputs final code.

Step 3: Communication protocol.
- Use structured messages with fields: sender, recipient, content, status.
- Maintain shared state: current code version, pending issues, iteration count.
- Set maximum iterations (e.g., 3 review cycles) to prevent endless loops.

Implement a memory system for an agent that helps users plan meals. The system should remember dietary preferences, past meals, and shopping lists across sessions.

Step 1: Design the memory architecture.
- Short-term memory: Current conversation history (last 20 messages).
- Long-term memory: Vector database storing user preferences and history.

Step 2: Define memory schemas.
- DietaryPreference: { user_id, preference_type, value, timestamp }
Types: 'allergies', 'dislikes', 'favorites', 'dietary_restrictions'
- MealHistory: { user_id, meal_name, date, rating, notes }
- ShoppingList: { user_id, items: [{ item, quantity, purchased }], created_date }

Step 3: Implement the memory tool.
- store_memory(user_id: str, memory_type: str, content: dict) → Confirms storage.
- retrieve_memories(user_id: str, query: str, memory_types: list) → Returns relevant memories.
- update_preference(user_id: str, preference_type: str, old_value: str, new_value: str) → Updates stored preference.

Step 4: Integration into agent loop.
1. User says: 'I'm allergic to shellfish. Plan dinner for tonight.'
2. BEFORE reasoning: Retrieve memories for user.
- retrieve_memories(user_id, 'dinner planning', ['DietaryPreference', 'MealHistory'])
3. OBSERVATION: Found preferences: allergic to shellfish, likes Italian cuisine, last 3 meals were pasta dishes.
4. THOUGHT: User is allergic to shellfish and has had pasta recently. I should suggest something different but still Italian-adjacent.
5. ACTION: Suggest risotto with chicken and vegetables.
6. AFTER response: Store this interaction.
- store_memory(user_id, 'MealHistory', { meal_name: 'risotto', date: today })

Step 5: Embedding and retrieval.
- Use a text embedding model (e.g., text-embedding-3-small) to embed memories.
- Store embeddings in vector database with metadata.
- Retrieve using semantic similarity to current query.
- Include memory age in relevance scoring (recent memories weighted higher).

Assume each tool provides exactly one external capability, and the language model can summarize retrieved text. An agent must search the web and email a summary. How many tools are required?

The prompt specifies one external capability per tool. Web search and sending email are two external capabilities; summarization is performed by the language model. Therefore two tools are required.

In the ReAct pattern, if an agent's action returns an error, what should the next 'Thought' typically do?

Step 1: The ReAct loop continues after observations, including error observations.
Step 2: The Thought step should reason about why the action failed.
Step 3: This enables adaptive behavior like retrying with different parameters.
Answer: The Thought should analyze the error and determine an alternative approach.

A dense-vector RAG system has a knowledge base of 50,000 documents. What is the first retrieval step when answering a user query?

In a dense-vector retrieval system, the query is embedded and compared with the precomputed document vectors to retrieve relevant context before generation. Other RAG systems can use keyword or hybrid retrieval; this stem specifies dense-vector retrieval.