rhachet-roles-bhrain 0.1.1 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/roles/architect/briefs/brains.replic/arc000.sources.[catalog].md +178 -0
- package/dist/roles/architect/briefs/brains.replic/arc101.concept.llm.[article].md +25 -0
- package/dist/roles/architect/briefs/brains.replic/arc102.concept.repl.[article].md +33 -0
- package/dist/roles/architect/briefs/brains.replic/arc103.concept.replic-brain.[article].md +35 -0
- package/dist/roles/architect/briefs/brains.replic/arc104.concept.context-window.[article].md +40 -0
- package/dist/roles/architect/briefs/brains.replic/arc105.concept.system-prompt.[article].md +44 -0
- package/dist/roles/architect/briefs/brains.replic/arc106.concept.tool-definition.[article].md +59 -0
- package/dist/roles/architect/briefs/brains.replic/arc107.concept.tool-call.[article].md +54 -0
- package/dist/roles/architect/briefs/brains.replic/arc108.concept.tool-result.[article].md +58 -0
- package/dist/roles/architect/briefs/brains.replic/arc109.concept.agentic-loop.[article].md +62 -0
- package/dist/roles/architect/briefs/brains.replic/arc110.concept.reasoning-trace.[article].md +58 -0
- package/dist/roles/architect/briefs/brains.replic/arc111.concept.react-pattern.[article].md +65 -0
- package/dist/roles/architect/briefs/brains.replic/arc112.concept.reflexion-pattern.[article].md +68 -0
- package/dist/roles/architect/briefs/brains.replic/arc113.concept.tree-of-thoughts.[article].md +76 -0
- package/dist/roles/architect/briefs/brains.replic/arc114.concept.self-consistency.[article].md +73 -0
- package/dist/roles/architect/briefs/brains.replic/arc115.concept.lats-pattern.[article].md +78 -0
- package/dist/roles/architect/briefs/brains.replic/arc116.concept.context-compaction.[article].md +71 -0
- package/dist/roles/architect/briefs/brains.replic/arc117.concept.subagent.[article].md +71 -0
- package/dist/roles/architect/briefs/brains.replic/arc118.concept.extended-thinking.[article].md +69 -0
- package/dist/roles/architect/briefs/brains.replic/arc119.concept.mcp.[article].md +78 -0
- package/dist/roles/architect/briefs/brains.replic/arc120.concept.session.[article].md +67 -0
- package/dist/roles/architect/briefs/brains.replic/arc121.concept.message.[article].md +79 -0
- package/dist/roles/architect/briefs/brains.replic/arc122.concept.plan-and-solve.[article].md +80 -0
- package/dist/roles/architect/briefs/brains.replic/arc150.concepts.treestruct.[article].md +126 -0
- package/dist/roles/architect/briefs/brains.replic/arc201.blueprint.claude-code.[article].md +417 -0
- package/dist/roles/architect/briefs/brains.replic/arc201.blueprint.claude-code.zoomin.reason.[article].md +507 -0
- package/dist/roles/architect/briefs/brains.replic/arc202.blueprint.codex.[article].md +354 -0
- package/dist/roles/architect/briefs/brains.replic/arc300.blueprints.comparison.[catalog].md +284 -0
- package/dist/roles/thinker/briefs/term=brain.atomic_vs_replic.md +8 -0
- package/package.json +3 -2
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# react-pattern
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
a prompting paradigm that interleaves reasoning traces with actions, producing explicit Thought → Action → Observation cycles that ground reasoning in real-world feedback.
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
react addresses a fundamental limitation of pure reasoning: hallucination. by forcing the model to take actions and observe actual results between reasoning steps, react grounds abstract thought in concrete feedback. this synergy of reasoning and acting enables more reliable task completion.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `reasoning-trace` — the "thought" component
|
|
14
|
+
- `tool-call` — the "action" component
|
|
15
|
+
- `tool-result` — the "observation" component
|
|
16
|
+
- `agentic-loop` — orchestrates the cycle
|
|
17
|
+
|
|
18
|
+
## pattern structure
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
Thought: I need to find information about X
|
|
22
|
+
Action: Search("X")
|
|
23
|
+
Observation: [search results]
|
|
24
|
+
Thought: Based on these results, I should check Y
|
|
25
|
+
Action: Read("file_y.txt")
|
|
26
|
+
Observation: [file contents]
|
|
27
|
+
Thought: Now I can answer the question
|
|
28
|
+
Answer: ...
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## benchmark performance
|
|
32
|
+
|
|
33
|
+
| benchmark | react vs baseline |
|
|
34
|
+
|-----------|-------------------|
|
|
35
|
+
| HotPotQA | competitive with CoT, lower hallucination (6% vs 14%) |
|
|
36
|
+
| ALFWorld | +34% over imitation learning |
|
|
37
|
+
| WebShop | significantly outperforms Act-only |
|
|
38
|
+
|
|
39
|
+
## tradeoffs
|
|
40
|
+
|
|
41
|
+
### strengths
|
|
42
|
+
- grounded in real observations
|
|
43
|
+
- lower hallucination rate
|
|
44
|
+
- interpretable decision process
|
|
45
|
+
- recovers from errors via feedback
|
|
46
|
+
|
|
47
|
+
### weaknesses
|
|
48
|
+
- structurally constrained (forced action after each thought)
|
|
49
|
+
- dependent on quality of retrieved information
|
|
50
|
+
- may force unnecessary actions
|
|
51
|
+
|
|
52
|
+
## comparison with pure CoT
|
|
53
|
+
|
|
54
|
+
| aspect | CoT | ReAct |
|
|
55
|
+
|--------|-----|-------|
|
|
56
|
+
| grounding | internal only | external observations |
|
|
57
|
+
| hallucination | higher | lower |
|
|
58
|
+
| flexibility | high | constrained by structure |
|
|
59
|
+
| task types | reasoning | reasoning + interaction |
|
|
60
|
+
|
|
61
|
+
## sources
|
|
62
|
+
|
|
63
|
+
- [ReAct: Synergizing Reasoning and Acting](https://arxiv.org/abs/2210.03629) — original paper (ICLR 2023)
|
|
64
|
+
- [Google Research Blog](https://research.google/blog/react-synergizing-reasoning-and-acting-in-language-models/) — overview
|
|
65
|
+
- [Comprehensive Guide to ReAct](https://www.mercity.ai/blog-post/react-prompting-and-react-based-agentic-systems) — practical guide
|
package/dist/roles/architect/briefs/brains.replic/arc112.concept.reflexion-pattern.[article].md
ADDED
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# reflexion-pattern
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
an agent architecture that adds explicit self-reflection after task attempts, storing verbal feedback in memory to improve performance on subsequent trials through "verbal reinforcement learning."
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
reflexion addresses a key limitation of single-attempt agents: they cannot learn from their mistakes within a session. by reflecting on failures and storing insights, the agent can iteratively improve without weight updates. this enables rapid adaptation and higher eventual success rates.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `agentic-loop` — base execution pattern
|
|
14
|
+
- `reasoning-trace` — reflection is a form of reasoning
|
|
15
|
+
- `context-window` — stores reflection memory
|
|
16
|
+
|
|
17
|
+
## pattern structure
|
|
18
|
+
|
|
19
|
+
```
|
|
20
|
+
Attempt 1:
|
|
21
|
+
[Execute task]
|
|
22
|
+
Result: Failed (test case 3)
|
|
23
|
+
|
|
24
|
+
Reflection:
|
|
25
|
+
"I failed because I didn't handle the edge case where
|
|
26
|
+
the input is empty. Next time I should check for
|
|
27
|
+
empty inputs before processing."
|
|
28
|
+
|
|
29
|
+
Attempt 2:
|
|
30
|
+
[Execute task with reflection in context]
|
|
31
|
+
Result: Passed
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## key components
|
|
35
|
+
|
|
36
|
+
| component | purpose |
|
|
37
|
+
|-----------|---------|
|
|
38
|
+
| actor | executes actions in environment |
|
|
39
|
+
| evaluator | scores trajectory (success/failure) |
|
|
40
|
+
| self-reflection | generates verbal feedback |
|
|
41
|
+
| memory | stores reflections for future attempts |
|
|
42
|
+
|
|
43
|
+
## benchmark performance
|
|
44
|
+
|
|
45
|
+
| benchmark | improvement |
|
|
46
|
+
|-----------|-------------|
|
|
47
|
+
| ALFWorld | +22% success rate with reflection |
|
|
48
|
+
| HotPotQA | improved accuracy over baseline ReAct |
|
|
49
|
+
| programming | higher pass rates on iterative debugging |
|
|
50
|
+
|
|
51
|
+
## vs other patterns
|
|
52
|
+
|
|
53
|
+
| pattern | learns from failure? | mechanism |
|
|
54
|
+
|---------|---------------------|-----------|
|
|
55
|
+
| ReAct | no | single attempt |
|
|
56
|
+
| Reflexion | yes | verbal memory |
|
|
57
|
+
| LATS | yes | tree search with backtracking |
|
|
58
|
+
|
|
59
|
+
## implementation notes
|
|
60
|
+
|
|
61
|
+
- reflection is stored as text in context or external memory
|
|
62
|
+
- number of attempts typically capped (e.g., 3-5)
|
|
63
|
+
- works best when failure modes are diverse
|
|
64
|
+
|
|
65
|
+
## sources
|
|
66
|
+
|
|
67
|
+
- [Reflexion: Language Agents with Verbal Reinforcement Learning](https://arxiv.org/abs/2303.11366) — original paper
|
|
68
|
+
- [AgentBench](https://arxiv.org/abs/2308.03688) — benchmark including reflexion variants
|
package/dist/roles/architect/briefs/brains.replic/arc113.concept.tree-of-thoughts.[article].md
ADDED
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# tree-of-thoughts
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
a deliberate problem-solving framework that explores multiple reasoning paths as a tree structure, using search algorithms (BFS/DFS) and evaluation to find optimal solutions.
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
tree of thoughts addresses the limitation of linear chain-of-thought: once a reasoning path is taken, there's no backtracking. by explicitly exploring multiple branches and evaluating intermediate states, ToT enables deliberate planning and can solve problems requiring lookahead that linear approaches cannot.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `reasoning-trace` — each node contains reasoning
|
|
14
|
+
- `llm` — generates and evaluates thoughts
|
|
15
|
+
|
|
16
|
+
## pattern structure
|
|
17
|
+
|
|
18
|
+
```
|
|
19
|
+
[Problem]
|
|
20
|
+
│
|
|
21
|
+
┌────────────┼────────────┐
|
|
22
|
+
│ │ │
|
|
23
|
+
[Thought A] [Thought B] [Thought C]
|
|
24
|
+
│ │ │
|
|
25
|
+
[eval: 0.8] [eval: 0.3] [eval: 0.9] ← best
|
|
26
|
+
│ │
|
|
27
|
+
[Thought A1] [Thought C1]
|
|
28
|
+
│ │
|
|
29
|
+
[eval: 0.6] [eval: 0.95] ← selected
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## key components
|
|
33
|
+
|
|
34
|
+
| component | purpose |
|
|
35
|
+
|-----------|---------|
|
|
36
|
+
| thought decomposition | break problem into steps |
|
|
37
|
+
| thought generator | propose multiple candidates |
|
|
38
|
+
| state evaluator | score intermediate states |
|
|
39
|
+
| search algorithm | BFS, DFS, or beam search |
|
|
40
|
+
|
|
41
|
+
## benchmark performance
|
|
42
|
+
|
|
43
|
+
| benchmark | ToT vs CoT |
|
|
44
|
+
|-----------|------------|
|
|
45
|
+
| Game of 24 | 74% vs 4% |
|
|
46
|
+
| Creative Writing | improved coherence |
|
|
47
|
+
| Crosswords | significantly higher solve rate |
|
|
48
|
+
|
|
49
|
+
## search strategies
|
|
50
|
+
|
|
51
|
+
| strategy | characteristic |
|
|
52
|
+
|----------|----------------|
|
|
53
|
+
| BFS | explore all options at each depth |
|
|
54
|
+
| DFS | explore deeply first, backtrack |
|
|
55
|
+
| beam search | keep top-k candidates at each level |
|
|
56
|
+
|
|
57
|
+
## cost tradeoff
|
|
58
|
+
|
|
59
|
+
ToT requires significantly more LLM calls than linear approaches:
|
|
60
|
+
- multiple thought proposals per step
|
|
61
|
+
- evaluation calls for each candidate
|
|
62
|
+
- may explore many branches
|
|
63
|
+
|
|
64
|
+
## vs other patterns
|
|
65
|
+
|
|
66
|
+
| pattern | exploration | backtracking |
|
|
67
|
+
|---------|-------------|--------------|
|
|
68
|
+
| CoT | linear | none |
|
|
69
|
+
| Self-Consistency | parallel paths, no interaction | none |
|
|
70
|
+
| ToT | tree structure | yes |
|
|
71
|
+
| LATS | tree + MCTS | yes, with learning |
|
|
72
|
+
|
|
73
|
+
## sources
|
|
74
|
+
|
|
75
|
+
- [Tree of Thoughts: Deliberate Problem Solving](https://arxiv.org/abs/2305.10601) — original paper (NeurIPS 2023)
|
|
76
|
+
- [CoALA](https://arxiv.org/abs/2309.02427) — positions ToT in agent framework
|
package/dist/roles/architect/briefs/brains.replic/arc114.concept.self-consistency.[article].md
ADDED
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
# self-consistency
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
a decoding strategy that samples multiple reasoning paths from the llm and selects the final answer by majority vote, leveraging the intuition that correct reasoning is more likely to converge on the same answer.
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
self-consistency exploits the stochastic nature of llm generation as a feature rather than a bug. different reasoning paths may make different mistakes, but correct paths tend to agree on the final answer. by sampling multiple times and voting, we reduce the impact of individual reasoning errors.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `reasoning-trace` — each sample produces a trace
|
|
14
|
+
- `llm` — generates multiple samples
|
|
15
|
+
|
|
16
|
+
## pattern structure
|
|
17
|
+
|
|
18
|
+
```
|
|
19
|
+
Question: What is the capital of Australia?
|
|
20
|
+
|
|
21
|
+
Sample 1: "Australia is in Oceania. Sydney is the largest city.
|
|
22
|
+
But the capital is Canberra." → Canberra
|
|
23
|
+
|
|
24
|
+
Sample 2: "Australia's government is in Canberra, which was
|
|
25
|
+
purpose-built as the capital." → Canberra
|
|
26
|
+
|
|
27
|
+
Sample 3: "The largest city is Sydney, which might be the
|
|
28
|
+
capital." → Sydney
|
|
29
|
+
|
|
30
|
+
Majority vote: Canberra (2/3)
|
|
31
|
+
Final answer: Canberra
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## key characteristics
|
|
35
|
+
|
|
36
|
+
- **embarrassingly parallel**: all samples independent
|
|
37
|
+
- **temperature > 0**: requires stochastic sampling
|
|
38
|
+
- **answer extraction**: must identify final answer in each trace
|
|
39
|
+
- **voting mechanism**: typically majority, can be weighted
|
|
40
|
+
|
|
41
|
+
## benchmark performance
|
|
42
|
+
|
|
43
|
+
| benchmark | improvement over greedy CoT |
|
|
44
|
+
|-----------|---------------------------|
|
|
45
|
+
| arithmetic | +17.9% (GSM8K) |
|
|
46
|
+
| commonsense | +11.0% (CommonsenseQA) |
|
|
47
|
+
| symbolic | significant gains |
|
|
48
|
+
|
|
49
|
+
## parameters
|
|
50
|
+
|
|
51
|
+
| parameter | effect |
|
|
52
|
+
|-----------|--------|
|
|
53
|
+
| num_samples | more samples = higher accuracy, higher cost |
|
|
54
|
+
| temperature | higher = more diverse samples |
|
|
55
|
+
| voting method | majority, weighted, etc. |
|
|
56
|
+
|
|
57
|
+
## cost analysis
|
|
58
|
+
|
|
59
|
+
self-consistency is more expensive than single-path CoT:
|
|
60
|
+
- linear cost increase with sample count
|
|
61
|
+
- typically 5-40 samples used
|
|
62
|
+
- parallelizable (latency ≈ single sample if concurrent)
|
|
63
|
+
|
|
64
|
+
## limitations
|
|
65
|
+
|
|
66
|
+
- requires extractable final answers
|
|
67
|
+
- expensive for long generations
|
|
68
|
+
- doesn't help if all paths fail similarly
|
|
69
|
+
|
|
70
|
+
## sources
|
|
71
|
+
|
|
72
|
+
- [Self-Consistency Improves Chain of Thought Reasoning](https://arxiv.org/abs/2203.11171) — original paper
|
|
73
|
+
- [Reasoning with LM Prompting Survey](https://github.com/zjunlp/Prompt4ReasoningPapers) — comparison with other methods
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# lats-pattern (language agent tree search)
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
an advanced agent framework that combines tree-of-thoughts with monte carlo tree search (MCTS), using external feedback and learned value functions to guide exploration of action sequences.
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
LATS addresses limitations of both linear agents (no backtracking) and static tree search (no learning). by incorporating MCTS principles — selection, expansion, simulation, backpropagation — LATS can learn from failed trajectories and allocate search effort efficiently toward promising paths.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `tree-of-thoughts` — tree structure for exploration
|
|
14
|
+
- `agentic-loop` — action execution
|
|
15
|
+
- `reflexion-pattern` — learning from feedback
|
|
16
|
+
|
|
17
|
+
## mcts components in LATS
|
|
18
|
+
|
|
19
|
+
| component | implementation |
|
|
20
|
+
|-----------|----------------|
|
|
21
|
+
| selection | UCB1-guided node choice |
|
|
22
|
+
| expansion | llm generates candidate actions |
|
|
23
|
+
| simulation | execute action, observe result |
|
|
24
|
+
| backpropagation | update values based on outcome |
|
|
25
|
+
|
|
26
|
+
## pattern structure
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
[Root State]
|
|
30
|
+
│
|
|
31
|
+
┌────────┼────────┐
|
|
32
|
+
│ │ │
|
|
33
|
+
[A:0.6] [B:0.8] [C:0.4] ← UCB1 selects B
|
|
34
|
+
│
|
|
35
|
+
┌────────┼────────┐
|
|
36
|
+
│ │ │
|
|
37
|
+
[B1:0.7] [B2:0.9] [B3:0.5] ← expand B, simulate
|
|
38
|
+
│
|
|
39
|
+
[success]
|
|
40
|
+
│
|
|
41
|
+
backpropagate +reward
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## benchmark performance
|
|
45
|
+
|
|
46
|
+
| benchmark | LATS performance |
|
|
47
|
+
|-----------|-----------------|
|
|
48
|
+
| HotPotQA | state-of-the-art among agent methods |
|
|
49
|
+
| WebShop | improved over ReAct/Reflexion |
|
|
50
|
+
| Programming | higher solve rates with search |
|
|
51
|
+
|
|
52
|
+
## key innovations over ToT
|
|
53
|
+
|
|
54
|
+
| aspect | ToT | LATS |
|
|
55
|
+
|--------|-----|------|
|
|
56
|
+
| exploration | static heuristic | learned UCB1 |
|
|
57
|
+
| feedback | evaluation only | environment + reflection |
|
|
58
|
+
| memory | none | experience buffer |
|
|
59
|
+
| replanning | from scratch | informed by history |
|
|
60
|
+
|
|
61
|
+
## computational cost
|
|
62
|
+
|
|
63
|
+
LATS is more expensive than simpler methods:
|
|
64
|
+
- multiple simulation trajectories
|
|
65
|
+
- value function updates
|
|
66
|
+
- but more sample-efficient than random exploration
|
|
67
|
+
|
|
68
|
+
## when to use
|
|
69
|
+
|
|
70
|
+
- complex multi-step tasks
|
|
71
|
+
- sparse reward signals
|
|
72
|
+
- when backtracking is valuable
|
|
73
|
+
- sufficient compute budget
|
|
74
|
+
|
|
75
|
+
## sources
|
|
76
|
+
|
|
77
|
+
- [Language Agent Tree Search (LATS)](https://arxiv.org/abs/2310.04406) — original paper (ICML 2024)
|
|
78
|
+
- [Understanding LLM Agent Planning Survey](https://arxiv.org/abs/2402.02716) — positions LATS in taxonomy
|
package/dist/roles/architect/briefs/brains.replic/arc116.concept.context-compaction.[article].md
ADDED
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# context-compaction
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
techniques for reducing the token count of accumulated context while preserving essential information, enabling long-running agent sessions within fixed context window limits.
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
as replic brains iterate through the agentic loop, context accumulates: tool results, conversation turns, reasoning traces. without compaction, the context window fills and the agent cannot continue. compaction strategies allow sessions to persist indefinitely while retaining relevant information.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `context-window` — the constraint being managed
|
|
14
|
+
- `llm` — may perform summarization
|
|
15
|
+
- `agentic-loop` — produces context to compact
|
|
16
|
+
|
|
17
|
+
## strategies
|
|
18
|
+
|
|
19
|
+
### summarization
|
|
20
|
+
condense earlier conversation/results into summaries:
|
|
21
|
+
```
|
|
22
|
+
[Original: 5000 tokens of tool results]
|
|
23
|
+
↓ summarize
|
|
24
|
+
[Summary: 200 tokens capturing key findings]
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
### sliding window
|
|
28
|
+
keep only the most recent N turns:
|
|
29
|
+
```
|
|
30
|
+
[turn 1] [turn 2] [turn 3] [turn 4] [turn 5]
|
|
31
|
+
↓ window of 3
|
|
32
|
+
[turn 3] [turn 4] [turn 5]
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
### hierarchical memory (MemGPT)
|
|
36
|
+
tier information by recency/importance:
|
|
37
|
+
```
|
|
38
|
+
L1 (context): current working set
|
|
39
|
+
L2 (recall): summarized past sessions
|
|
40
|
+
L3 (archive): compressed long-term storage
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### selective retention
|
|
44
|
+
keep only tool results that inform current task:
|
|
45
|
+
```
|
|
46
|
+
[file read A] [file read B] [file read C]
|
|
47
|
+
↓ task now focuses on C
|
|
48
|
+
[file read C]
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
## tradeoffs
|
|
52
|
+
|
|
53
|
+
| strategy | preserves | loses |
|
|
54
|
+
|----------|-----------|-------|
|
|
55
|
+
| summarization | gist | verbatim details |
|
|
56
|
+
| sliding window | recency | early context |
|
|
57
|
+
| hierarchical | structure | fast access to old data |
|
|
58
|
+
| selective | relevance | potentially useful info |
|
|
59
|
+
|
|
60
|
+
## implementation in replic brains
|
|
61
|
+
|
|
62
|
+
| system | compaction approach |
|
|
63
|
+
|--------|---------------------|
|
|
64
|
+
| claude code | auto-summarization when context fills |
|
|
65
|
+
| codex cloud | full context (large windows) |
|
|
66
|
+
| aider | git diff-based context |
|
|
67
|
+
|
|
68
|
+
## sources
|
|
69
|
+
|
|
70
|
+
- [MemGPT: Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560) — hierarchical memory
|
|
71
|
+
- [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) — summarization patterns
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# subagent
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
a child agent spawned by a parent agent, operating with its own isolated context window to perform a delegated subtask before returning results.
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
subagents address two key challenges: context exhaustion and task parallelization. by delegating subtasks to agents with fresh context windows, the parent can tackle larger problems without filling its own context. subagents can also run in parallel for independent tasks.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `agentic-loop` — both parent and child run loops
|
|
14
|
+
- `context-window` — isolation is the key benefit
|
|
15
|
+
- `tool-definition` — subagent spawning is a tool
|
|
16
|
+
|
|
17
|
+
## pattern
|
|
18
|
+
|
|
19
|
+
```
|
|
20
|
+
Parent Agent (main context)
|
|
21
|
+
│
|
|
22
|
+
├── Task tool: "explore codebase for auth patterns"
|
|
23
|
+
│ │
|
|
24
|
+
│ └── Subagent (fresh context)
|
|
25
|
+
│ ├── Glob, Grep, Read...
|
|
26
|
+
│ └── Returns summary
|
|
27
|
+
│
|
|
28
|
+
└── Continues with summary in context
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## key characteristics
|
|
32
|
+
|
|
33
|
+
- **isolated context**: subagent starts fresh
|
|
34
|
+
- **focused task**: single delegated objective
|
|
35
|
+
- **returns results**: output injected into parent context
|
|
36
|
+
- **may be typed**: different subagent types for different tasks
|
|
37
|
+
|
|
38
|
+
## subagent types (claude code)
|
|
39
|
+
|
|
40
|
+
| type | purpose | tools available |
|
|
41
|
+
|------|---------|-----------------|
|
|
42
|
+
| Explore | codebase exploration | Glob, Grep, Read |
|
|
43
|
+
| Plan | implementation planning | Read, planning tools |
|
|
44
|
+
| general-purpose | complex multi-step tasks | all tools |
|
|
45
|
+
|
|
46
|
+
## parallelization
|
|
47
|
+
|
|
48
|
+
subagents enable parallel execution:
|
|
49
|
+
```
|
|
50
|
+
Parent: "search for auth and search for database patterns"
|
|
51
|
+
│
|
|
52
|
+
├── Subagent A: auth exploration ──────┐
|
|
53
|
+
│ ├── (parallel)
|
|
54
|
+
└── Subagent B: database exploration ──┘
|
|
55
|
+
│
|
|
56
|
+
└── Combine results
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
## tradeoffs
|
|
60
|
+
|
|
61
|
+
| benefit | cost |
|
|
62
|
+
|---------|------|
|
|
63
|
+
| context isolation | summarization loss when returning |
|
|
64
|
+
| parallelization | coordination complexity |
|
|
65
|
+
| fresh start | loses parent context unless passed |
|
|
66
|
+
| focused execution | additional API calls |
|
|
67
|
+
|
|
68
|
+
## sources
|
|
69
|
+
|
|
70
|
+
- [Building Agents with Claude Agent SDK](https://www.anthropic.com/engineering/building-agents-with-the-claude-agent-sdk) — subagent patterns
|
|
71
|
+
- [Claude Code Documentation](https://docs.anthropic.com) — Task tool specification
|
package/dist/roles/architect/briefs/brains.replic/arc118.concept.extended-thinking.[article].md
ADDED
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
# extended-thinking
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
a capability that allows an llm to allocate additional computation (serial test-time compute) to reasoning before producing a final response, controlled by a token budget.
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
extended thinking enables "thinking harder" about complex problems. by giving the model a dedicated budget for internal reasoning, it can explore approaches, verify its work, and catch errors before committing to an answer. this is particularly valuable for coding, math, and analysis tasks.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `llm` — must support thinking mode
|
|
14
|
+
- `reasoning-trace` — thinking produces traces
|
|
15
|
+
- `context-window` — thinking consumes budget tokens
|
|
16
|
+
|
|
17
|
+
## mechanism
|
|
18
|
+
|
|
19
|
+
```
|
|
20
|
+
[User Query]
|
|
21
|
+
│
|
|
22
|
+
↓
|
|
23
|
+
[Extended Thinking: up to N tokens]
|
|
24
|
+
- "Let me consider the approaches..."
|
|
25
|
+
- "First approach: ..."
|
|
26
|
+
- "Wait, that won't work because..."
|
|
27
|
+
- "Better approach: ..."
|
|
28
|
+
│
|
|
29
|
+
↓
|
|
30
|
+
[Final Response: informed by thinking]
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
## key characteristics
|
|
34
|
+
|
|
35
|
+
- **token budget**: user specifies max thinking tokens (1k-128k)
|
|
36
|
+
- **hybrid mode**: can be toggled on/off per request
|
|
37
|
+
- **serial compute**: sequential reasoning steps
|
|
38
|
+
- **varying visibility**: thinking may be hidden or shown
|
|
39
|
+
|
|
40
|
+
## budget guidelines
|
|
41
|
+
|
|
42
|
+
| budget | suitable for |
|
|
43
|
+
|--------|--------------|
|
|
44
|
+
| 1k-4k | simple analysis |
|
|
45
|
+
| 4k-16k | moderate complexity |
|
|
46
|
+
| 16k-64k | complex coding/math |
|
|
47
|
+
| 64k-128k | deep research |
|
|
48
|
+
|
|
49
|
+
## integration with tools
|
|
50
|
+
|
|
51
|
+
extended thinking can be combined with tool use:
|
|
52
|
+
- think before deciding which tools to use
|
|
53
|
+
- think after receiving tool results
|
|
54
|
+
- "think" tool forces explicit reasoning pause
|
|
55
|
+
|
|
56
|
+
## vs other patterns
|
|
57
|
+
|
|
58
|
+
| pattern | mechanism |
|
|
59
|
+
|---------|-----------|
|
|
60
|
+
| CoT | inline reasoning in response |
|
|
61
|
+
| ToT | explore multiple branches |
|
|
62
|
+
| Extended thinking | dedicated compute budget |
|
|
63
|
+
| Self-consistency | multiple samples, voting |
|
|
64
|
+
|
|
65
|
+
## sources
|
|
66
|
+
|
|
67
|
+
- [Claude's Extended Thinking](https://www.anthropic.com/news/visible-extended-thinking) — announcement
|
|
68
|
+
- [Using Extended Thinking](https://support.claude.com/en/articles/10574485-using-extended-thinking) — documentation
|
|
69
|
+
- [The "think" Tool](https://www.anthropic.com/engineering/claude-think-tool) — tool integration
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# mcp (model context protocol)
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
an open protocol that standardizes how llm applications connect to external tools, data sources, and services through a unified interface.
|
|
6
|
+
|
|
7
|
+
## .why
|
|
8
|
+
|
|
9
|
+
mcp solves the N×M integration problem: without a standard, every llm application must build custom integrations for every tool. with mcp, tool providers implement the protocol once, and any mcp-compatible application can use it. this enables a rich ecosystem of interoperable tools.
|
|
10
|
+
|
|
11
|
+
## dependsOn
|
|
12
|
+
|
|
13
|
+
- `tool-definition` — mcp defines tool schemas
|
|
14
|
+
- `tool-call` — mcp routes tool invocations
|
|
15
|
+
- `tool-result` — mcp returns structured results
|
|
16
|
+
|
|
17
|
+
## architecture
|
|
18
|
+
|
|
19
|
+
```
|
|
20
|
+
┌─────────────────┐ ┌──────────────────┐
|
|
21
|
+
│ LLM Application │ │ MCP Server │
|
|
22
|
+
│ (Claude Code) │────▶│ (filesystem) │
|
|
23
|
+
└─────────────────┘ └──────────────────┘
|
|
24
|
+
│ │
|
|
25
|
+
│ MCP Protocol │
|
|
26
|
+
│◀─────────────────────▶│
|
|
27
|
+
│ │
|
|
28
|
+
▼ ▼
|
|
29
|
+
┌─────────────────┐ ┌──────────────────┐
|
|
30
|
+
│ MCP Server │ │ MCP Server │
|
|
31
|
+
│ (database) │ │ (github) │
|
|
32
|
+
└─────────────────┘ └──────────────────┘
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## protocol components
|
|
36
|
+
|
|
37
|
+
| component | purpose |
|
|
38
|
+
|-----------|---------|
|
|
39
|
+
| tools | actions the server exposes |
|
|
40
|
+
| resources | data the server provides |
|
|
41
|
+
| prompts | templates for common operations |
|
|
42
|
+
| transports | communication channels (stdio, http) |
|
|
43
|
+
|
|
44
|
+
## tool definition in mcp
|
|
45
|
+
|
|
46
|
+
```json
|
|
47
|
+
{
|
|
48
|
+
"name": "read_file",
|
|
49
|
+
"description": "Read contents of a file",
|
|
50
|
+
"inputSchema": {
|
|
51
|
+
"type": "object",
|
|
52
|
+
"properties": {
|
|
53
|
+
"path": { "type": "string" }
|
|
54
|
+
},
|
|
55
|
+
"required": ["path"]
|
|
56
|
+
}
|
|
57
|
+
}
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
## benefits
|
|
61
|
+
|
|
62
|
+
- **extensibility**: add new tools without changing core
|
|
63
|
+
- **standardization**: consistent interface across providers
|
|
64
|
+
- **composability**: combine multiple servers
|
|
65
|
+
- **permission control**: allowedTools/disallowedTools
|
|
66
|
+
|
|
67
|
+
## adoption
|
|
68
|
+
|
|
69
|
+
| system | mcp support |
|
|
70
|
+
|--------|-------------|
|
|
71
|
+
| claude code | native, primary integration mechanism |
|
|
72
|
+
| cursor | supported |
|
|
73
|
+
| cline | supported |
|
|
74
|
+
|
|
75
|
+
## sources
|
|
76
|
+
|
|
77
|
+
- [Model Context Protocol](https://modelcontextprotocol.io/) — specification
|
|
78
|
+
- [Building Agents with Claude Agent SDK](https://www.anthropic.com/engineering/building-agents-with-the-claude-agent-sdk) — MCP integration
|