From 3226278e220777569b89bfdabfc49a7ab659142c Mon Sep 17 00:00:00 2001
From: William Fu-Hinthorn <13333726+hinthornw@users.noreply.github.com>
Date: Mon, 12 Feb 2024 15:18:48 -0800
Subject: [PATCH] conclusion

---
 examples/llm-compiler/LLMCompiler.ipynb | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/examples/llm-compiler/LLMCompiler.ipynb b/examples/llm-compiler/LLMCompiler.ipynb
index 676e12492..e77331bda 100644
--- a/examples/llm-compiler/LLMCompiler.ipynb
+++ b/examples/llm-compiler/LLMCompiler.ipynb
@@ -919,6 +919,20 @@
     "print(step[END][-1].content)"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "c647d5f3-5e00-4449-9cec-5a9f438c9cff",
+   "metadata": {},
+   "source": [
+    "## Conclusion\n",
+    "\n",
+    "Congrats on building your first LLMCompiler agent! I'll leave you with some known limitations to the implementation above:\n",
+    "\n",
+    "1. The planner output parsing format is fragile if your function requires more than 1 or 2 arguments. We could make it more robust by using streaming tool calling.\n",
+    "2. Variable substitution is fragile in the example above. It could be made more robust by using a fine-tuned model and a more robust syntax (using e.g., Lark or a tool calling schema)\n",
+    "3. The state can grow quite long if you require multiple re-planning runs. To handle, you could add a message compressor once you go above a certain token limit.\n"
+   ]
+  },
   {
    "cell_type": "code",
    "execution_count": null,