@shaykec/bridge 0.4.25 → 0.4.27

package/modules/adr-writing/quick-ref.md

@@ -0,0 +1,57 @@
+# ADR Quick Reference
+
+## What Is an ADR?
+
+A short document capturing one architecture decision, its context, and consequences.
+
+## Five Sections
+
+| Section | Purpose |
+|--------|---------|
+| Title | Short, descriptive |
+| Status | proposed, accepted, deprecated, superseded |
+| Context | Options, constraints, forces |
+| Decision | What we decided |
+| Consequences | Positive, negative, follow-up |
+
+## Status Lifecycle
+
+```
+Proposed → Accepted
+Accepted → Deprecated (no replacement)
+Accepted → Superseded (replaced by new ADR)
+```
+
+## When to Write
+
+- Decision affects multiple teams or services
+- Reversing would be costly
+- Future developers will wonder "why?"
+
+## When to Skip
+
+- Trivial or easily reversible
+- Temporary workaround
+- Purely operational (unless architectural impact)
+
+## File Layout
+
+```
+docs/adr/
+  0001-use-redis-for-sessions.md
+  0002-migrate-to-graphql.md
+```
+
+## Pitfalls to Avoid
+
+- Writing too late
+- One ADR with many decisions (split them)
+- No link to implementation
+- Only positive consequences (be honest)
+- Never updating status when decisions change
+
+## Tools
+
+- **adr-tools** — CLI for create, link, supersede
+- **Log4brains** — Web UI, Git integration
+- **Markdown template** — Often enough

package/modules/adr-writing/quiz.md

@@ -0,0 +1,73 @@
+# ADR Writing Quiz
+
+## Question 1
+
+What is the primary purpose of an ADR?
+
+A) To document every code change
+B) To capture the reasoning behind significant architecture decisions
+C) To replace design documents
+D) To track project milestones
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: ADRs document why we made important architectural decisions. They preserve context for future readers who would otherwise wonder "why did we do this?" -->
+
+## Question 2
+
+Which section of an ADR describes the options and constraints that led to the decision?
+
+A) Decision
+B) Consequences
+C) Context
+D) Status
+
+<!-- ANSWER: C -->
+<!-- EXPLANATION: Context explains the forces, options, and constraints. It sets the stage so readers understand why the decision mattered. -->
+
+## Question 3
+
+When should you use the status "Superseded"?
+
+A) When the decision was never implemented
+B) When the decision is replaced by a newer ADR
+C) When the decision is temporarily paused
+D) When the decision is under review
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Superseded means another ADR has replaced this one. You should link to the new ADR. Use Deprecated when the decision is no longer followed but not replaced. -->
+
+## Question 4
+
+A common pitfall when writing ADRs is:
+
+A) Writing them too early
+B) Writing them too late, after memory has faded
+C) Using too many bullet points
+D) Including code samples
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Write ADRs when you make the decision. If you wait, you forget nuances, options considered, and tradeoffs. Late ADRs are often incomplete or inaccurate. -->
+
+## Question 5
+
+Where should ADRs typically be stored?
+
+A) In a separate wiki
+B) In the project repository (e.g., docs/adr/)
+C) In email threads
+D) In a project management tool
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Storing ADRs in the repo keeps them versioned, co-located with code, and discoverable. They travel with the project and are easy to find. -->
+
+## Question 6
+
+Why is it important to document negative consequences in an ADR?
+
+A) To discourage future changes
+B) To provide honest tradeoffs for future readers making related decisions
+C) To satisfy auditors
+D) To reduce the document length
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Negative consequences help future readers understand tradeoffs. If they face similar choices, they know what downsides to watch for. Honesty builds trust. -->

package/modules/adr-writing/resources.md

@@ -0,0 +1,29 @@
+# ADR Writing — Resources
+
+## Foundational Articles
+
+- [Documenting Architecture Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) — Michael Nygard's original ADR article.
+- [ADR GitHub Organisation](https://adr.github.io) — ADR formats, templates, and tools.
+- [MADR (Markdown ADR)](https://adr.github.io/madr/) — Lightweight, Markdown-based ADR template.
+
+## Guides and Examples
+
+- [Architecture Decision Records (Nat Pryce)](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) — Context and motivation.
+- [ADR Examples — Joel Parker Henderson](https://github.com/joelparkerhenderson/architecture-decision-record) — Large collection of ADR examples.
+- [Think Before You Leap — Thomas Guest](https://tomguest.net/writing/think-before-you-leap/) — When and how to use ADRs.
+
+## Tooling
+
+- [adr-tools](https://github.com/npryce/adr-tools) — Command-line tool for managing ADRs.
+- [Log4brains](https://github.com/thomvaill/log4brains) — Web-based ADR catalog with Git integration.
+- [adr-manager](https://github.com/adr/madr) — MADR format and tooling.
+
+## Books and Longer Reads
+
+- **Documenting Software Architectures** by Bass, Clements, Kazman — Broader documentation context.
+- [Martin Fowler — Architecture Guide](https://martinfowler.com/architecture/) — Architecture documentation practices.
+
+## Videos
+
+- [YOW! — Documenting Architecture Decisions](https://www.youtube.com/results?search_query=ADR+architecture+decision+record) — Conference talks on ADRs.
+- [InfoQ — ADR in Practice](https://www.infoq.com/) — Search for "architecture decision record" talks.

package/modules/adr-writing/walkthrough.md

@@ -0,0 +1,64 @@
+# ADR Writing Walkthrough — Learn by Doing
+
+## Step 1: Identify a Decision Worth Documenting
+
+**Task:** Think of a recent technical decision (yours or your team's): framework choice, database, API style, deployment model. Write one sentence: "We decided X because Y."
+
+**Question:** Would a developer joining in 6 months benefit from knowing this? What would they assume incorrectly without it?
+
+**Checkpoint:** You have a concrete decision and a reason someone would care.
+
+---
+
+## Step 2: Draft the Context Section
+
+**Task:** For that decision, write the **Context** section. Include: (1) the problem or opportunity, (2) the options considered, (3) the constraints (time, team, tech stack).
+
+**Question:** What did you leave out? Is there a constraint that might change and invalidate the decision?
+
+**Checkpoint:** Context is 2–4 paragraphs; a reader can see why the decision mattered.
+
+---
+
+## Step 3: Write the Decision and Consequences
+
+**Task:** Add **Decision** (one clear paragraph) and **Consequences** (at least one positive and one negative).
+
+**Question:** Why is it valuable to document negative consequences? What happens if you only list positives?
+
+**Checkpoint:** Decision is unambiguous; consequences are honest and useful for future readers.
+
+---
+
+## Step 4: Choose Status and Add Metadata
+
+<!-- hint:buttons type="single" prompt="What status applies to your ADR?" options="A: Proposed,B: Accepted,C: Superseded" -->
+<!-- hint:card type="tip" title="Use 'proposed' for open decisions; 'accepted' once the team has committed" -->
+
+**Task:** Add a **Title** and **Status** (proposed or accepted). If the decision is already made, use accepted. Add a date.
+
+**Question:** When would you use "proposed" vs "accepted"? What does "superseded" mean for an older ADR?
+
+**Checkpoint:** The ADR has a clear status and can be filed in `docs/adr/`.
+
+---
+
+## Step 5: Link to Code (Optional but Valuable)
+
+<!-- hint:code language="markdown" highlight="1,2" -->
+
+**Task:** If the decision is implemented, add a line like "Implemented in `[path/to/file]`" or "See PR #123." If not yet implemented, note "To be implemented."
+
+**Question:** Why does linking to code help? What if the code has drifted from the decision?
+
+**Checkpoint:** Future readers can trace from ADR to implementation.
+
+---
+
+## Step 6: When *Not* to Write an ADR
+
+**Task:** Consider these: (a) "We use 2 spaces for indentation." (b) "We chose React over Vue." (c) "We restarted the server to fix the bug." Which would you document as an ADR, and which would you skip?
+
+**Question:** What's the cost of over-documenting? When does the overhead outweigh the benefit?
+
+**Checkpoint:** You can articulate the threshold: significant, costly-to-reverse, or confusing-without-context decisions merit an ADR.

package/modules/ai-agents/content.md

@@ -0,0 +1,120 @@
+# AI Agents — Tool Use, Planning, and Autonomous Workflows
+
+<!-- hint:slides topic="AI agents: observe-think-act loop, tool use and MCP, planning strategies, memory, and multi-agent systems" slides="6" -->
+
+## What Makes an Agent?
+
+An **AI agent** combines an LLM with **tools** and a **control loop**. Instead of just generating text, the agent can take actions: search the web, run code, query a database, call APIs. The loop: observe → think → act → observe.
+
+## The Agent Loop
+
+```mermaid
+flowchart TB
+    subgraph loop["Agent Loop"]
+        O[Observe: state, tools, feedback]
+        T[Think: plan, decide]
+        A[Act: call tool or respond]
+    end
+    O --> T --> T --> A
+    A -->|Tool result| O
+    A -->|Final answer| End[End]
+```
+
+1. **Observe** — Current state, available tools, user input, tool outputs
+2. **Think** — Plan next step, choose tool or respond
+3. **Act** — Execute tool call or produce final answer
+4. **Observe** — Incorporate tool result; repeat until done
+
+## Tool Use / Function Calling
+
+**Function calling** (or tool use) lets the model request structured actions. You define tools with:
+
+- **Name** — e.g., `search_web`
+- **Description** — What it does; the model uses this to choose
+- **Parameters** — JSON schema (inputs the tool needs)
+
+The model outputs a tool call (name + arguments); your code executes it and returns the result; the model sees the result and continues.
+
+## MCP — Model Context Protocol
+
+**MCP** is an open standard for exposing tools to LLMs. Instead of each app defining its own format, MCP defines:
+
+- How tools are described (schemas)
+- How to invoke them
+- How to stream results
+
+Tools (file systems, databases, APIs, custom logic) can be packaged as MCP servers and used by any MCP-compatible client.
+
+## Planning Strategies
+
+| Strategy | Idea |
+|----------|------|
+| **ReAct** | Reason + Act: alternate reasoning steps and tool calls in the same output |
+| **Chain-of-thought planning** | Plan steps in text before acting; then execute |
+| **Reflexion** | Reflect on failures; update plan and retry |
+
+The agent chooses when to use tools vs. when to answer directly.
+
+## Memory
+
+- **Short-term** — The current conversation (context window). All prior turns and tool results.
+- **Long-term** — External store (vector DB, key-value) the agent can read/write across sessions.
+
+Agents often use RAG for long-term knowledge and a session store for the current task.
+
+## Multi-Agent Systems
+
+Multiple agents can cooperate:
+
+```mermaid
+flowchart TB
+    subgraph orch["Orchestrator"]
+        O[Coordinator Agent]
+    end
+    subgraph workers["Workers"]
+        A1[Researcher]
+        A2[Coder]
+        A3[Reviewer]
+    end
+    O --> A1
+    O --> A2
+    O --> A3
+    A1 --> O
+    A2 --> O
+    A3 --> O
+```
+
+- **Orchestrator** — Delegates subtasks, merges results
+- **Specialists** — Researcher (search), Coder (write code), Reviewer (check quality)
+
+## Safety
+
+| Concern | Mitigation |
+|---------|------------|
+| **Sandboxing** | Run tools in isolated env; limit file/network access |
+| **Human-in-the-loop** | Require approval for sensitive actions (e.g., deploy, pay) |
+| **Guardrails** | Validate inputs/outputs; block dangerous patterns |
+| **Rate limits** | Prevent runaway loops and cost explosions |
+
+## Real-World Examples
+
+- **Claude Code** — Coding agent with file edit, shell, web search
+- **Research agents** — Search, summarize, cite
+- **Customer support** — Query KB, create tickets, escalate
+
+## Current Limitations
+
+- **Hallucinated tool calls** — Model may invent tool names or parameters
+- **Infinite loops** — Agent keeps retrying without progress
+- **Cost** — Many tool calls = many tokens
+- **Brittleness** — Unclear tool descriptions lead to wrong choices
+
+---
+
+## Key Takeaways
+
+1. **Agent = LLM + tools + loop** — observe, think, act, repeat
+2. **Tool use** — Define schemas; model chooses and calls; you execute
+3. **MCP** — Standard way to expose tools to LLMs
+4. **Planning** — ReAct, CoT, Reflexion; balance reasoning vs. acting
+5. **Safety** — Sandbox, human-in-the-loop, guardrails

package/modules/ai-agents/exercises.md

@@ -0,0 +1,82 @@
+# AI Agents Exercises
+
+## Exercise 1: Write a Tool Schema
+
+**Task:** Write a JSON schema for a tool that searches a vector database. Parameters: `query` (string), `top_k` (number, default 5), `filter` (optional object with `category`). Include a clear description the model can use to decide when to call it.
+
+**Validation:**
+- [ ] Has name, description, parameters
+- [ ] Parameters match the spec (query, top_k, filter)
+- [ ] Description explains when to use (e.g., "semantic search over indexed documents")
+
+**Hints:**
+1. Description: "Search the vector database for documents similar to the query."
+2. `top_k`: integer, default 5
+3. `filter`: optional, e.g., `{ "category": "docs" }`
+
+---
+
+## Exercise 2: Implement the Agent Loop (Pseudocode)
+
+**Task:** Write pseudocode for the main agent loop: (1) Receive user message, (2) Call LLM with tools, (3) If LLM returns tool call, execute and append result to messages, (4) Repeat until LLM returns final answer. Include a max-iterations guard.
+
+**Validation:**
+- [ ] Loop: get LLM response → if tool call, execute → add result → repeat
+- [ ] Max iterations to prevent infinite loops
+- [ ] Stops when LLM returns text (no tool call)
+
+**Hints:**
+1. `while True` with `max_steps` counter
+2. Check response type: `tool_calls` vs `content`
+3. Append `{"role": "tool", "content": result}` and loop
+
+---
+
+## Exercise 3: Plan for Failure Modes
+
+**Task:** List 5 failure modes for an agent that uses web search + summarization. For each, propose a mitigation (retry, fallback, user message, etc.).
+
+**Validation:**
+- [ ] Covers: no results, timeout, malformed response, rate limit, irrelevant results
+- [ ] Each has a concrete mitigation
+
+**Hints:**
+1. No results → retry with different query or tell user
+2. Timeout → retry once, then fail gracefully
+3. Malformed → validate schema; ask model to fix or skip
+4. Rate limit → backoff, queue, or inform user
+5. Irrelevant → re-rank, filter, or prompt for refinement
+
+---
+
+## Exercise 4: Design Human-in-the-Loop
+
+**Task:** Your agent can create calendar events. Design a human-in-the-loop flow: when does the agent pause? What does the user see? What can they do (approve, reject, edit)? Draw or describe the flow.
+
+**Validation:**
+- [ ] Agent pauses before creating (or similar destructive action)
+- [ ] User sees proposed action (e.g., event details)
+- [ ] User can approve, reject, or edit
+- [ ] Describes what happens after each choice
+
+**Hints:**
+1. Agent proposes → "Create event: X at Y. Approve? [Y/N/Edit]"
+2. Edit → agent updates proposal
+3. Approve → agent executes
+4. Reject → agent stops or suggests alternative
+
+---
+
+## Exercise 5: Compare Agent Architectures
+
+**Task:** Compare a single-agent design vs. a multi-agent design for "Answer customer support questions using our docs." For each, list: (a) tools/agents, (b) pros, (c) cons, (d) when you'd choose it.
+
+**Validation:**
+- [ ] Single: one agent + search + docs tools; simpler, may be slower
+- [ ] Multi: orchestrator + retrieval agent + answer agent; more modular, more complex
+- [ ] Clear recommendation with justification
+
+**Hints:**
+1. Single: one agent does search + read + answer
+2. Multi: retrieval agent finds docs, answer agent synthesizes
+3. Choose single for simplicity; multi for scale or specialization

package/modules/ai-agents/module.yaml

@@ -0,0 +1,42 @@
+slug: ai-agents
+title: "AI Agents — Tool Use, Planning, and Autonomous Workflows"
+version: 1.0.0
+description: "Learn how AI agents combine LLMs with tools, the agent loop, MCP, planning strategies, and safety considerations."
+category: ai-and-llm
+tags: [ai-agents, tool-use, planning, autonomous, mcp, function-calling]
+difficulty: advanced
+
+xp:
+  read: 20
+  walkthrough: 50
+  exercise: 30
+  quiz: 25
+  quiz-perfect-bonus: 15
+
+time:
+  quick: 5
+  read: 25
+  guided: 60
+
+prerequisites: [llm-fundamentals]
+related: [ai-pair-programming, rag-fundamentals]
+
+triggers:
+  - "What are AI agents?"
+  - "How do AI agents use tools?"
+  - "What is function calling?"
+  - "How do autonomous AI workflows work?"
+
+visuals:
+  diagrams: [diagram-mermaid, diagram-architecture]
+  quiz-types: [quiz-drag-order, quiz-matching]
+  playground: bash
+  slides: true
+
+sources:
+  - url: "https://docs.anthropic.com/en/docs/build-with-claude/tool-use"
+    label: "Anthropic Tool Use Documentation"
+    type: docs
+  - url: "https://modelcontextprotocol.io"
+    label: "Model Context Protocol (MCP)"
+    type: docs

package/modules/ai-agents/quick-ref.md

@@ -0,0 +1,60 @@
+# AI Agents Quick Reference
+
+## Agent = LLM + Tools + Loop
+
+```
+Observe → Think → Act → Observe (repeat)
+```
+
+## Tool Schema
+
+```json
+{
+  "name": "tool_name",
+  "description": "What it does (model uses this to decide)",
+  "parameters": {
+    "query": { "type": "string" },
+    "top_k": { "type": "number", "default": 5 }
+  }
+}
+```
+
+## MCP
+
+- **Model Context Protocol** — Standard for tool exposure
+- Tools as MCP servers; any MCP client can use them
+- [modelcontextprotocol.io](https://modelcontextprotocol.io)
+
+## Planning Strategies
+
+| Strategy | Approach |
+|----------|----------|
+| ReAct | Alternate reasoning + tool calls |
+| CoT planning | Plan in text, then execute |
+| Reflexion | Reflect on failures, retry |
+
+## Memory
+
+| Type | Scope |
+|------|-------|
+| Short-term | Current conversation (context) |
+| Long-term | Vector DB, key-value across sessions |
+
+## Safety Checklist
+
+- [ ] Sandbox tools (limit file/network)
+- [ ] Human-in-the-loop for sensitive actions
+- [ ] Guardrails (input/output validation)
+- [ ] Max iterations / rate limits
+
+## Multi-Agent
+
+- **Orchestrator** — Delegates, merges results
+- **Specialists** — Focused tools and tasks
+
+## One-Liners
+
+- **Loop** — Observe, think, act, repeat.
+- **Tools** — Define schema; model chooses and calls.
+- **MCP** — Standard interface for tools.
+- **Safety** — Sandbox, human approval, guardrails.

package/modules/ai-agents/quiz.md

@@ -0,0 +1,103 @@
+# AI Agents Quiz
+
+## Question 1
+
+What are the three main components of an AI agent?
+
+A) Model, data, and compute
+B) LLM, tools, and a control loop
+C) Prompt, response, and feedback
+D) Training, inference, and deployment
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: An AI agent combines an LLM (for reasoning and language), tools (for actions like search, code execution), and a control loop (observe → think → act → observe). -->
+
+## Question 2
+
+What does MCP stand for and what does it provide?
+
+A) Model Context Protocol — a standard way to expose tools to LLMs
+B) Machine Learning Pipeline — a training workflow
+C) Multi-tenant Compute Platform — cloud infrastructure
+D) Modular Context Processor — a type of neural layer
+
+<!-- ANSWER: A -->
+<!-- EXPLANATION: MCP (Model Context Protocol) is an open standard for defining and exposing tools to LLMs, enabling interoperability between different agents and tool servers. -->
+
+## Question 3
+
+In the ReAct pattern, what does the agent alternate between?
+
+A) Training and inference
+B) Reasoning and tool calls
+C) Prompting and fine-tuning
+D) Search and retrieval
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: ReAct (Reason + Act) alternates between explicit reasoning steps and tool calls. The model thinks, then acts, then thinks again based on the result. -->
+
+## Question 4
+
+Drag these agent loop steps into the correct order:
+
+<!-- VISUAL: quiz-drag-order -->
+
+A) Observe → Think → Act → Observe (repeat)
+B) Act → Think → Observe → Act
+C) Think → Observe → Act → Think
+D) Observe → Act → Think → Observe
+
+<!-- ANSWER: A -->
+<!-- EXPLANATION: The agent loop is: Observe (state, tools, feedback) → Think (plan, decide) → Act (call tool or respond) → Observe (incorporate result) → repeat until done. -->
+
+## Question 5
+
+Which safety measure limits what an agent can do, even if it tries?
+
+A) Better prompting
+B) Sandboxing
+C) Few-shot examples
+D) Lower temperature
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Sandboxing runs tools in an isolated environment with restricted file system, network, and process access. It limits damage even if the model requests dangerous actions. -->
+
+## Question 6
+
+What is a common limitation of AI agents?
+
+A) They are always faster than humans
+B) They can hallucinate tool names or parameters
+C) They never make mistakes with tools
+D) They don't need guardrails
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Agents can hallucinate tool calls — inventing tool names, wrong parameters, or calling tools at the wrong time. Validation and clear schemas help reduce this. -->
+
+## Question 7
+
+<!-- VISUAL: quiz-drag-order -->
+
+Put these agent loop steps in the correct order (from start to iteration):
+
+A) Act (invoke tool or respond to user)
+B) Observe (get state, tools, user input)
+C) Think (reason, plan, decide next action)
+D) Observe (incorporate tool result or feedback)
+
+<!-- ANSWER: B,C,A,D -->
+<!-- EXPLANATION: The agent first observes the current state, then thinks (reasons and plans), acts (calls a tool or responds), and observes again to incorporate the result. Steps B through D repeat until the task is done. -->
+
+## Question 8
+
+<!-- VISUAL: quiz-matching -->
+
+Match each agent pattern to its description:
+
+A) ReAct → 1) Chain of thought followed by tool call; alternate reasoning and action
+B) Tool use → 2) Agent decides which external capability to invoke
+C) Plan-and-execute → 3) Break task into steps, execute each step
+D) Reflexion → 4) Agent reflects on failures and updates strategy before retrying
+
+<!-- ANSWER: A1,B2,C3,D4 -->
+<!-- EXPLANATION: ReAct alternates reasoning and action. Tool use lets the agent invoke external capabilities. Plan-and-execute breaks work into steps. Reflexion uses failure reflection to improve. -->

package/modules/ai-agents/resources.md

@@ -0,0 +1,30 @@
+# AI Agents — Resources
+
+## Official Docs
+
+- [Anthropic Tool Use](https://docs.anthropic.com/en/docs/build-with-claude/tool-use) — Claude tool use, schemas, and examples.
+- [Model Context Protocol (MCP)](https://modelcontextprotocol.io) — MCP specification and ecosystem.
+
+## Videos
+
+- [AI Explained — AI Agents](https://www.youtube.com/results?search_query=AI+Explained+agents) — Agent architectures and tool use.
+- [Andrej Karpathy — AI Agents](https://www.youtube.com/results?search_query=Andrej+Karpathy+agents) — Technical deep dives.
+- [Fireship — AI Agents in 5 Minutes](https://www.youtube.com/results?search_query=Fireship+AI+agents) — Quick overview.
+
+## Articles
+
+- [Lilian Weng — LLM Agents](https://lilianweng.github.io/posts/2023-06-23-agent/) — Agent survey: ReAct, tool use, memory.
+- [Chip Huyen — Building AI Agents](https://huyenchip.com/) — Production considerations.
+- [Simon Willison — Agents](https://simonwillison.net/series/ai/) — Practical agent patterns.
+
+## Tools & Frameworks
+
+- [LangChain](https://docs.langchain.com) — Agent frameworks, tools, and chains.
+- [LlamaIndex](https://docs.llamaindex.ai) — Data frameworks and agent tooling.
+- [Claude API](https://docs.anthropic.com/en/api) — Tool use with Claude.
+- [OpenAI Function Calling](https://platform.openai.com/docs/guides/function-calling) — Tool use with GPT.
+
+## Papers
+
+- [ReAct: Synergizing Reasoning and Acting](https://arxiv.org/abs/2210.03629) — ReAct pattern.
+- [Reflexion](https://arxiv.org/abs/2303.11366) — Self-reflection for agents.