How Packs Could Evolve into an Agentic Framework

[Bill_French]

The folks at Coda (specifically Eric Koleda) have intimated in another forum about the future of Packs:l

“…to extend the Packs platform…”

I have a tough time understanding how the Pack architecture could be agentic. How will it have the power and performance necessary to embrace large contexts, long-term memory requirements, and asynchronous/event-based communications? Packs seem deeply sandboxed and unsuitable as a framework for agentic development, the way LangGraph and Mastro work. If Grammarly needs to call an agent, how would a Pack-notable for its inability to support external communications-provide an agentic interface?

So, I did some thinking and research.

Clarifying Packs’ Current Capabilities and Limitations

Packs are essentially serverless JavaScript/TypeScript extensions that run on Coda’s infrastructure. They enhance docs by adding formulas, actions (for buttons/automations), sync tables (for pulling external data), and column formats. Key points relevant to my doubts:

• Sandboxing: Yes, Packs are isolated for security—they don’t have unrestricted access to a doc’s full data. Users must explicitly pass parameters (e.g., via formulas or actions), and Packs declare their capabilities upfront (e.g., network access). This prevents rogue behavior but doesn’t inherently block agentic features; Coda could extend permissions for approved agent workflows.

• External Communications: This seems like a misunderstanding. Packs do support external interactions via HTTP requests, OAuth authentication, and API calls. For example, the Google Calendar Pack pulls events from Google’s API, and the Slack Pack sends messages. They’re not “unable” to communicate externally; they’re designed for it, as long as it’s declared in the Pack’s code. If Grammarly (which has a Coda integration via widget and potentially Pack-like features) needs to “call an agent,” the agent could use these same mechanisms to interface with Grammarly’s API. But can a pack serve as an endpoint? I’m still fuzzy on this.

• Power and Performance: Packs executions are capped at ~1 minute to prevent abuse, but Coda already supports async patterns (e.g., for sync tables that poll data over time). Large-scale processing happens on Coda’s servers, not client-side, so scalability is handled by their backend.

• Contexts and Memory: Current Packs don’t natively handle “large contexts” (e.g., processing massive doc data) or persistent memory beyond simple caching. Formulas/actions are stateless by default. However, Coda docs themselves provide database-like tables for storage, and Packs can interact with them indirectly.

These aren’t insurmountable for agents—agents being autonomous systems that reason, plan, use tools, and remember across interactions. Frameworks like LangGraph (which builds graph-based workflows with LangChain) or Maestro (e.g., see CrewAI’s orchestration) are general-purpose, but Coda could adapt Packs by layering agent-specific features on top.

How Packs Could Evolve into an Agentic Framework

Based on the quote from Eric Koleda (“extend the Packs platform to be the way to build agentic functionality… upgrade existing Packs to become agents”), this isn’t about forcing Packs into something they’re not—it’s about augmenting them. Coda already has “Coda AI” (built-in LLM features for summarization, generation, etc.), so they have the AI backbone. Here’s a plausible path for making Packs agentic, addressing specific requirements:

1. Defining Agents in Packs:

   • Packs could add a new building block: “Agent definitions.” Similar to how you define formulas or actions today, you’d script an agent’s behavior (e.g., prompts, tools, decision logic) in JS/TS.
   • Example: A Pack could expose an “Agent” as a doc element—like a button that triggers an agent workflow or a table that logs agent interactions.
   • Upgrade path: Existing Packs (e.g., Grammarly for advanced text analysis) could add agent layers without rewriting everything. The Pack’s core tools (e.g., API calls) become the agent’s “tools,” and Coda’s AI handles the reasoning loop.

2. Handling Large Contexts:

   • Coda’s backend could integrate with high-capacity LLMs (e.g., via partnerships like OpenAI, which already has a Coda Pack). Agents wouldn’t process “large contexts” in one go; they’d use techniques like chunking, summarization, or RAG (Retrieval-Augmented Generation) over the doc.
   • In a doc, the agent pulls relevant data (e.g., from tables) on-demand, approved by the user. This avoids overwhelming the sandbox—context is built iteratively, not loaded wholesale.

3. Long-Term Memory:

   • Use Coda’s native tables/databases as memory storage. An agent Pack could write/read from a “memory table” in the doc, persisting state across sessions.
   • For example: An agent analyzing Grammarly suggestions could store user preferences or past corrections in a table, querying it for future runs. This is “long-term” without needing external databases, and it’s secure within the doc’s permissions.

4. Power, Performance, and Loops:

   • Agentic loops (e.g., plan-act-observe) could run on Coda’s servers with extended timeouts or async chaining (building on current sync table mechanics).
   • Performance: Coda hosts everything, so they can optimize for scale (e.g., parallel executions). Unlike local frameworks, this offloads compute to their cloud, similar to how Vercel or Replit host agent demos.

5. Grammarly Example (or Similar Integrations):

   • If Grammarly needs to “call an agent,” the upgraded Pack could define the agent as an intermediary: The Pack provides tools (e.g., HTTP to Grammarly’s API for checks), and the agent reasons over them (e.g., “Analyze this text, suggest edits, confirm with user, apply changes”).
   • Interface: In a doc, this appears as an “Agent button” or automation. External comms happen via the Pack’s existing HTTP capabilities—no need to break the sandbox, as it’s all routed through declared APIs.

This isn’t hypothetical; Coda’s ecosystem already supports AI Packs (e.g., OpenAI for GPT/DALL-E in docs), so extending to agents is a natural step. It’s like turning Packs into “tool providers” for Coda AI’s agent runtime.

Why This Is a Doable (and Good) Strategy

Coda isn’t trying to compete with general frameworks like LangGraph (for arbitrary agent graphs) or Maestro (for multi-agent orchestration)—they’re focusing on Coda-specific agents that live in docs (Shishire said exactly this in the Twist video). Here’s why it’s feasible and advantageous:

• Doability:

  • Technical Fit: Packs are already modular and extensible. Coda controls the platform, so they can add agent primitives (e.g., LLM calls, memory APIs) without breaking backward compatibility. Upgrades could be opt-in, like adding an “agent: true” flag to a Pack.
  • Security via Sandbox: Rather than a weakness, this is a strength—agents would require explicit user consents (e.g., “Allow this agent to access table X”), preventing hallucinations or data leaks. External comms stay controlled.
  • Performance Scaling: Coda’s serverless model can handle agent loops via batching/async, and large contexts/memory via doc integration. They’ve managed similar for Coda AI features.
  • Timeline: The quote notes “still working on details,” so expect iterative rollouts (e.g., beta with simple agents, then full upgrades).

• Why It’s a Good Strategy:

  • Leverages Existing Ecosystem: Thousands of Packs exist (e.g., Jira, Slack, Google). Upgrading them to agents means instant value—e.g., a Jira Pack becomes an agent that not only syncs issues but prioritizes them autonomously. No need for devs to learn a new framework.
  • Integrated with Workflows: Agents in Packs would embed directly in docs, where teams already collaborate. This beats standalone tools: Memory in tables, contexts from doc data, actions as buttons/automations.
  • User-Friendly for Coda Users: Devs familiar with Packs (simple JS) can build agents without mastering LangGraph’s complexity. For non-devs, it’s “stackable” with Coda’s no-code elements.
  • Security and Compliance: Sandboxing ensures agents are safer than open frameworks, ideal for enterprise (e.g., no accidental API exposures).
  • Business Angle: Unifies Coda’s product line (docs + AI + integrations), reducing tool sprawl. It’s “agentic” where it matters—in collaborative docs—without overpromising full autonomy.

Aspect	Current Packs Limitation	Agentic Extension (Plausible)	Benefit Over LangGraph/Maestro
Sandboxing	Restricted data access	User-approved doc scopes for agents	Safer; integrated with Coda permissions
External Comms	HTTP/API only (declared)	Agents use Pack tools for calls	Seamless; no extra setup needed
Large Contexts	Stateless formulas	LLM chunking + doc RAG	Doc-native; handles Coda-scale data
Long-Term Memory	None (or cache)	Store in Coda tables	Persistent, queryable in docs
Performance	1-min cap	Async loops on Coda servers	Scalable; no local resource drain
Grammarly-Like Use	Basic API calls	Agent reasons over API results	Upgrades integration to proactive

In short, this strategy plays to Coda’s strengths: A secure, integrated platform where agents enhance docs without reinventing the wheel. It’s doable because Coda owns the stack and can iterate safely. If it feels mismatched now, it’s likely because details are pending—watch for announcements in their community or blog.

Circling back to this observation:

they’re focusing on Coda-specific agents that live in docs

I am doing all of this in Coda with Mastro. Coda is an ideal orchestrator.

[Agile_Dynamics]

An excellent outline of possible future directions for Coda AI. Thanks @Bill_French

Coda has stated that existing Packs can be made into Agents in some way.
Like you, I am scratching my head how this can be done without significant re-writing of the Pack’s internals.

But if it can be brought about, this will be a major coup for Coda indeed. Because Coda is indeed an EXCELLENT orchestration vehicle for sophisticated Agentic Workflows that automate Business SOPs (Standard Operating Processes). This orchestration strength, combined with Grammarly’s ubiquitous UX and excellent distributed AI engine will be a VERY powerful force in the market.

Add to that the AI work done by Superhuman to automate users ‘policies and processes’ for handling workflows using simple prompts; and BOOM! you have pure dynamite.

However…

Building Packs remains a task for developers with coding skills.
So building Agents and Agentic Workflows in this way still requires coding skills.

At Agile Dynamics, we have been deploying AI Agentic Workflows using an alternative approach.
It does not require any coding in Python, Js, or Typescript - just normal Coda Formulas.

Our Agentic Workflows are a mesh of AI Agents that pass work to each other. The orchestration is done by Coda Formulas. Our clients are determined to keep Agent-building strictly in the realms of business management, makers who are whizz-kids at spreadsheets and formulas. They wish to avoid the involvement of IT specialists or developers.

Our framework lets non-programmers build AI Agents and complete Agentic Workflows without the need for Packs or Pack Development.

Each Agent is autonomous, asynchronos, action oriented, and built using standard Coda techniques that most Coda makers are familiar with.

The Agents can be built to use the default built-in Coda AI features, or we can use AI Packs that provide access to other LLM models. They use PAcks to access external data sources as usual. And there is a specific Pack for RAG use-cases. But makers do not need to understand the internals of any of these packs.

Each Agent is built as a Coda Table with columns for inputs, results, formulas, and AI Inferences.
The AI Inference columns use a Coda Formula to construct the prompt and include data from any other columns or controls in the document. Each AI response is parsed by formulas to extract the resulting data.

Action formulas are used to update the ‘memory’ of the workflow; ie: insert or change rows in Coda tables to record the progress of the workflow, and to trigger real-world actions.

To start an Agent, you just AddRow() to the agent’s table with the initial values, and then RunActions(Start!) to push the button on that row. The formula in the Start! button does all the orchestration using standard Coda formulas. This includes starting other agents as needed.

This has another major advantage over other Agentic apporaches (like Langgraph etc). We use Coda formulas to do all the computations and data manipulations that LLMs are not good at; giving us complete deterministic behavior - whichis VITAL in executing Business SOPs.

So we only use LLMs for the steps that require knowledge, jusdement, and expertise - which LLMs are good at.

We use structured formats for prompting and for respponses (we found YAML to be best for this).

AI ‘sophisticates’ will argue that these are not fully autonomous agents; they are controlled by deterministic formulas, and do not explore options and devise their own strategies. They are (at best) Agentic Workflows or Chains. A Rose by any other name! They work amazingly well!

With this approcah we are tackling the final fronteer of Business Automation; those steps in our SOPs that, up until now, could NOT be automated with formulas or code because they needed human knowledge, expertise, judgement and thinking.

By uploading the required knowledge to Vector Databases and using our RAG Pack to include that knowkedge in our workflows, we have finally been able to automate almost ALL the steps in workflows for our clients in their most important SOPs - and without the need for programming.

@Bill_French shows a way forward for those who are happy to write code for their agents.
We are showing an alternative path for those who wish to avoid code and just use formulas.

If you are interested, here are two videos that illustrate this approach; the first is a short overview, the secons is a longer, more detailed dive into the techniques used.

Respect, Max

Build AI AGENTS in CODA

Nocode AI Agents with CODA

[Bill_French]

… and BOOM! you have pure dynamite.

I was anticipating - and BOOM! you have agile dynamics. ;-).

By uploading the required knowledge to Vector Databases and using our RAG Pack to include that knowkedge in our workflows, we have finally been able to automate almost ALL the steps in workflows for our clients in their most important SOPs - and without the need for programming.

This is an impressive code-free abstraction that yields significant benefits. I love the lane focus you’ve created. At the root of all heightened enterprise productivity and performance are operating procedures.

I don’t think any business is happy about writing code, especially in the current climate of generative AI. In many circles, particularly those influenced by the irrational claims of the ‘1000x’ AI enthusiasts on LinkedIn, ‘software engineering’ is often considered a ‘cooked’ role. We can all agree that this is a vastly oversimplified and mischaracterized view. I predicted in 2023 that we’re going to need more software because there’s so much more we can now do with software.

No/low-code agentic workflows in Coda are fantastic for empowering business users and rapidly automating structured processes. As needs grow—requiring more autonomy, memory, dynamic tool use, and complex orchestration—frameworks like Mastra become essential. They unlock the full potential of agentic AI, at a cost, of course.

For many teams, the sweet spot is clearly no-code for quick wins. Hone this craft and framework. Lean into code-based frameworks as ambitions and complexity increase, if at all.

You aren’t using Grammarly?

[Agile_Dynamics]

@Bill_French

You aren’t using Grammarly?

Ouch! Actually I just IGNORED Grammarly in this incident.
I am travelling today so it was a ‘brain to keyboard’ dump.
Duh!

[Bill_French]

Ha ha! Ignore AI at your peril. But, here’s the irony! Even Grammarly needs oversight.

[Agile_Dynamics]

Hybrid AI Architecture in Coda

We are having a lot of success with Coda Agentic Workflows that combine generative AI (LLMs) with predictive AI (machine learning) together.

LLMs are terrible at understanding numerical data. Not just arithmetic, but understanding relative values or ANY reasoning with numbers.

The predictive AI models can be trained on the numerical data contained in our tables. Then they can be used as Tools from within an LLM agent to do the reasoning with numerical data. They have a much deeper ‘understanding’ of the numerical values and their relationships.

We are using Google’s TensorFlow library to build, train, and execute these neural networks. I will publish our ML pack shortly with more details.

The combination of Coda formulas for deterministic processing and orchestration, LLM prompts for comprehension & reasoning, plus the ML neural networks for classification & predictive reasoning with numerical tables, is proving to be an amazing and successful architecture.

And we have built this in a way that non-programmer business managers can use; a nocode solution.

The pack implements a limited set of ML features, but enough to create and use both classification models and regression models based on any Coda table.

This leads me to wonder if Coda Brain is also using a similar Hybrid AI Architecture (@noah ) ?

When I have some time, I will publish the ML Pack and provide examples.

Max

(no Grammarly tokens were harmed during this post)

[Nina_Ledid]

This is incredible work from both of you—thank you for laying it out so clearly for the community.

As someone building apps in Coda for business process automation, I often find that what a business user deems a ‘working workflow’ is very different from what I’d call a well-structured, normalized system.

A lot of effort goes into explaining why refactoring is needed and how to rebuild a workflow with proper architecture—especially when the user already thinks it’s working fine.

I imagine this challenge becomes even more critical with agent workflows, where structure and state management matter even more.

I’d love to hear how you think about debugging or auditing agent workflows (whether Pack-based or formula-based). What strategies or structures do you use to trace or inspect what an agent has done across its steps?

[Agile_Dynamics]

@Nina_Ledid …You are talking about the concepts known as ‘Evals’ in AI and ‘Test Driven Development (TDD)’ in software engineering.

I am working on a project presently with a major Fintech client to explore the best way to implement this in Coda.

Basically, we have built a doc that automates the testing of our Agents. We have the test cases in our data tables. We have copies of our AI Agents in tables. And we have a table of test cases that executes when we click on the ‘big blue TEST button’.

Each row of the test cases table has a canvas column containing a button that has a CFL procedure to run a single test.

That procedure will set up the test data, invoke the agent being tested, and use a prompt to compare the result with the ‘expected’ result, and save tbe ‘score’; green if it matches, amber if its a close match, red otherwise. (In current AI parlance these are called “Evals”.)

So we can encode a set of tests for each agent, and run those tests anytime we change an agent.

In fact, the principle behind TDD is that we should encode the tests BEFORE we build the agent!

This way we ‘define’ what the agent should do by encoding the tests it must pass. At least thats the goal. And since the system records all the test results, it can be reviewed by the dreaded autitors.

However, we are still experimenting with this approach.
It is proving difficult to implement the kinds of version-control we would be used to in code management systems like Github.

And the test runs can be very slow since each AI inference can take a few seconds. So we may need to optimize the test-run (evals) to only run for changed agents.

I hope to see an industry standard framework for this to emerge soon, as building our own is time consuming.

But in Fintech (and other industries) we MUST be able to prove that agents have been regression-tested for every deployment into production.

Max

[Gareth_Simpson1]

@Bill_French

hey’d use techniques like chunking, summarization, or RAG (Retrieval-Augmented Generation) over the doc.

Definitely this. Maybe some sort of visual UI - maybe a toggle, that exposes how it’s been indexed by the ai - llke how you caption image - something that feedbacks to the user how the RAG is interpreting this - would help documents authors optimize certain areas for ai.

@Bill_French

Use Coda’s native tables/databases as memory storage. An agent Pack could write/read from a “memory table” in the doc, persisting state across sessions.

This needs to be a feature with UI and settings - probably on a per-doc and per-workspace basis - sharable with the team.

@Bill_French

Integrated with Workflows: Agents in Packs would embed directly in docs, where teams already collaborate. This beats standalone tools: Memory in tables, contexts from doc data, actions as buttons/automations.

Agents being able to make comments on row’s please.

@Bill_French

Performance: Coda hosts everything, so they can optimize for scale (e.g., parallel executions). Unlike local frameworks, this offloads compute to their cloud, similar to how Vercel or Replit host agent demos.

If we have to pay for performance, fine - but some pricing options about how much CPU and memory we dedicate to tasks please.

Leverages Existing Ecosystem : Thousands of Packs exist (e.g., Jira, Slack, Google). Upgrading them to agents means instant value.

Yes but getting this right is problematic interface wise. Don’t try to automate the process completely - like maybe via an IDE style interface?? But making use the the exsisting pack’s ecosystem is cool - maybe an ‘AI Compliant’ pack badge.

[Bill_French]

@Nina_Ledid

how you think about debugging or auditing agent workflows (whether Pack-based or formula-based). What strategies or structures do you use to trace or inspect what an agent has done across its steps?

Sorry for the long overdue response.

Let’s reset the conversation by examining an alternative tool that may be positioned to disrupt Slack and Coda.

A lot changes when you can build an agent this simple and effortlessly. It’s a dang document, and this should have been possible in Coda, like last year at the latest.

This is Den. It is an early contender for what comes after Slack, or Coda, for that matter. It is a framework for building agent-driven workspaces where you can chat, write, and create primitive tables - a few of the essential features of Slack. It also provides workspaces that can co-exist with agents, allowing for easy construction by both technical and non-technical workers.

Den is a YC startup that asserts context is essential to agentic processes. They’re right. AI cannot perform without context. This reality bodes well for Grammarly with integration to Coda, where contexts can (and must) thrive. But it’s not a simple matter of syncing data to Coda or passing tables and documents to a Pack. The contexts must also come from sub-agents that are typically influenced by MCP integrations. Den, of course, supports MCP natively and can use several different LLMs.

Example…

I have a Den agent that pulls contexts from a Firebase data store of 20 million rows through a sub-agent. It does this without explicit instructions from a user, and the resulting contexts include only the required data needed for the primary agent’s objective. Most interesting is that this process is one of several steps in a workflow. Coda will have to become a very different animal to achieve these types of workflows that lean on agents.

Den’s documents and tables are primitive, but they’re enough to demonstrate the likely role this and others will play as disruptors in the enterprise workspace segment. Our work has not changed much, but the way we will achieve progress and perform tasks is undeniably evolving rapidly. This article lays out some additional observations.

This screenshot is today’s output of the agent shown above. Bear in mind, this is a straightforward autonomous workflow, but it demonstrates how simple it is to gather sources, add a little context, and produce helpful documents which, themselves, may become dynamic contexts for additional downstream agentic processes. Development teams tend to miss the ‘flywheel’ effect of agentic contexts.

@Nina_Ledid

I often find that what a business user deems a ‘working workflow’ is very different from what I’d call a well-structured, normalized system.

Indeed. But the very essence of ‘workflow’ is evolving when agents are introduced.

@Agile_Dynamics

So we can encode a set of tests for each agent, and run those tests anytime we change an agent.

As you can imagine, with Den, building evals is no less daunting. You still need to undertake the challenging task of developing evaluation processes. However, unlike Coda, you have a new tool on the table - MCP. We’re building agents that build evals and also execute them, assess outcomes, and report their findings. One then faces the reality that you we eval the evaluators, a topic for another thread.

[Bill_French]

@Agile_Dynamics

LLMs are terrible at understanding numerical data. Not just arithmetic, but understanding relative values or ANY reasoning with numbers.

The predictive AI models can be trained on the numerical data contained in our tables. Then they can be used as Tools from within an LLM agent to do the reasoning with numerical data. They have a much deeper ‘understanding’ of the numerical values and their relationships.

Spot-on. Training predictive AI models specifically on numerical data (e.g., tabular datasets) allows them to capture relationships and patterns far better than a general-purpose LLM. Integrating these models as tools within an LLM agent is a smart approach—it leverages the LLM’s natural language strengths for context and orchestration while offloading numerical reasoning to a specialized model that “understands” the data’s structure and relationships more deeply. This hybrid setup can significantly enhance performance on tasks requiring numerical insight, like financial analysis or scientific data interpretation.

How will Coda overcome this inherent number-centric LLM limitation?

MCP supports multi-agent architectures, where specialized models can delegate tasks (e.g., numerical analysis) to other agents or tools, simplifying the orchestration of complex workflows. I hate the idea of deep investment in model training only to learn that the hurdle is effortless scaled with a simple MCP integration.