CodaClaw: Run OpenClaw-like Agentic Workflows inside CODA

Showcase & Tips Doc Show and Tell
1

pumpexAnnotatedImage
pumpexAnnotatedImage1804×855 407 KB

This is a screenshot of a typical Agentic Workflow using Coda & Superhuman Go

(1) Superhuman Go AI Agents

While reading a key document (Engineer’s Report of a large Mine), the user clicks on the superhuman icon on the right of the screen and selects the CodaClaw agent from the list.
This agent reads the current screen and knows to start the Industrial Pump Configuration workflow in Coda.

(2) The “CodaClaw” Agent Pack

The agent uses the Coda MCP Server to access the workflow document, to read the SKILLS pages and ‘execute’ the configuration process defined therein.

(3) Coda Document Tables = MEMORY

This workflow uses regular Coda Tables to store the results of the process. One of these tables becomes the Bill Of Materials (BOM) needed to build the High Capacity Water Pump needed for the situation described in the Engineer’s Report.

(4) Coda Pages = SKILLS & REFERENCES

The document has a hierarchy of Pages and Subpages that contain the SKILLS and REFERENCES needed for the agent to do its work.

(5) Skills Pages = PROCESS

The SKILLS Sub-Pages contain the business logic needed for each task in the workflow. They are written in English but define the necessary branches and loops that the Agent must ‘execute’ to perform the process correctly. They capture the ‘know-how’ of the human experts who normally do this work.

(6) Decision Tables = LOGIC

The REFERENCES Sub-Pages contain the Knowledge Base needed by the process. In our use case, these are in the form of Decision Tables, a compact and concise way to express the complicated rules used to configure these complex engineering solutions. Decision Tables use “fuzzy logic” rather than the predicate logic of IF-THEN-ELSE formulas. That is, they describe the “Judgments” and “trade-offs” that a human would exercise.

(7) Skills Prompt AI Agent = CONTEXT

The Agent reads the SKILLS pages to understand the process, then begins to run through the whole process - no user prompting or pausing - completely autonomous.

(8) AI Agent Implements Skills = EXECUTION

The AI Agent reads the required SKILLS pages as required and ‘executes’ the process described in them. These SKILLS are written with great precision and attention to datail. They are programs written in English; understandable to humans and LLM alike.

(9) Agent Uses MCP to Update Tables = ACTIONS

The AI Agent emits commands to update the Coda Data Model by reading, updating, inserting, and deleting data in the Tables. The Superhuman Agent can read and understand the Coda data model schema. As the Agent works, it provides a ‘trace’ of its actions.

(10) Process Repeats Until Complete = LOOP

The Agent loops through the SKILLS and MCP Actions until the process is complete. If it encounters a problem, it logs the issue, sends a notification to a manager, and stops the process.

12 Likes
2

Here is a typical SKILLS page that describes to the AI how to execute the procedue.
It is written is a combination of plain English and ‘pseudo-code’ to define the logis with precision’

(We call the resulting grammer “SaiL” (Structured AI Language) - and it works amazingly well.
Both humans and AI understand exactly what is being defined.

ConfigurePump
Type: Process Skill
log to HISTORY "ConfigurePump started"
update TASK set Status = "Running", Current Attempt = 1

run skill ExtractParameters

find thisrow in TASK
if thisrow.Status = "ERROR: Review Required" then stop end if

delete rows from CONFIGURATION
create row in CONFIGURATION (Component Section = "Headrace", Retry Flag = false)
create row in CONFIGURATION (Component Section = "PumpEngine", Retry Flag = false)
create row in CONFIGURATION (Component Section = "Tailrace", Retry Flag = false)

run skill EvaluateHeadrace
run skill EvaluatePumpEngine
run skill EvaluateTailrace
run skill ValidateCompatibility

find thisrow in TASK
set attempt = thisrow.Current Attempt

find thisrow in CONFIGURATION where Component Section = "Validation Result"
set result = thisrow.Selected Component

while result = "Illegal" and attempt < 5
    run skill Backtrack

    find thisrow in CONFIGURATION where Component Section = "Headrace" and Retry Flag = true
    if found then run skill EvaluateHeadrace end if

    find thisrow in CONFIGURATION where Component Section = "PumpEngine" and Retry Flag = true
    if found then run skill EvaluatePumpEngine end if

    find thisrow in CONFIGURATION where Component Section = "Tailrace" and Retry Flag = true
    if found then run skill EvaluateTailrace end if

    run skill ValidateCompatibility

    set attempt = attempt + 1
    update TASK set Current Attempt = attempt

    find thisrow in CONFIGURATION where Component Section = "Validation Result"
    set result = thisrow.Selected Component
end while

if result = "Illegal" then
    update TASK set Status = "ERROR: Failed -- no legal configuration found"
    log to HISTORY "ERROR: ConfigurePump failed: backtrack limit reached"
    stop
end if

run skill BuildBOM
log to HISTORY "ConfigurePump complete"
3 Likes
3

Congratulations, @xyzhackerone_xyz , that is absolutely brilliant!

It just blows my mind that you were able to build out this solution using Superhuman Go, which means that it now works from any surface. The user doesn’t even need to know that this solution uses Coda, let alone having to access any particular Coda doc.

The user can work within any work surface they are most comfortable in (be that email, some custom tool, etc), hit the Superhuman-Go button, select the corresponding agent and it executes!

2 Likes
4

The snippet below illustrates how we use “Fuzzy Logic” and decision tables to harness the power of the AI to evaluate complex situations and make JUDGEMENTS that we could never express as pure formulas..

navigate to page DT Headrace
read the decision table from that page

Find the best matching row in the DT_HEADRACE markdown table where:
  solidcontent falls within Solid Content Min to Solid Content Max range
  and fluidtype matches or is compatible with the row Fluid Type value
  and flowrate falls within Flow Rate Min to Flow Rate Max range
  and Recommended != excluded

Apply the fuzzy guidance listed on the DT Headrace page.

set selection = matched Recommended
set reason = matched Notes

update CONFIGURATION
  set Selected Component = selection, Reason = reason, Retry Flag = false
  where Component Section = "Headrace"

The fuzzy logic entry in the decision tree is…

Fuzzy guidance:
- At 10-14% solids with borderline abrasive classification, prefer HR-300
  if site history suggests underestimation of solid content.

This captures the kind of thinking a human expert would use when doing this work.
There are dozens of such fuzzy rules in this configurator

3 Likes
5

An important part of any serious agentic workflow is the need to continiously evaluate the quality of the work.

In this use case we have a special compatability eval that checks each configuration proposed by the AI and detects any issues. It then gets the AI to re-evaluate its choices and propose an alternative solution until it passes the test (or it exceeds the re-try limit).

Read conflictreason and reason about which component is the primary source.
Identify the section -- Headrace, PumpEngine, or Tailrace -- most implicated.
set section = identified section
find thisrow in CONFIGURATION where Component Section = section
set currentselection = thisrow.Selected Component
update CONFIGURATION
set Retry Flag = true, Excluded Option = currentselection
    where Component Section = section
delete rows from CONFIGURATION where Component Section = "Validation Result"
log to HISTORY "Backtrack attempt " & attempt & ": marked " & section & " for retry, excluding " & currentselection

Notice how the prompt mixes plain English and the pseudo-code syntax to give a very precise definition of the process.

Modern LLMs are so well trained in all programming and formula grammers, that they have no problem understanding exactly what is required.

2 Likes
6

Over the last two years, we have been refining our Knowledge Management techniques to maximize the information content with a minimum number of tokens, so it all fits easily into the AI Context Window (which is rarely more than 1MB of text).

Low token count is not just to save money, but to minimize hallucination, lost-in-the-middle, and lose-the-plot errors that grow geometrically with token count.

One technique we found to work extremely well is to express the business logic in a DECISION TABLE. These have been used for decades in engineering and economics to capture the complex web of dependencies between PARAMETERS, CONDITIONALS, RULES, TRIGGERS, and ACTIONS using “Fuzzy Logic”.

In normal logic, a condition (C) is either TRUE or FALSE. In Fuzzy Logic it can range from 0% (False) to 100% (True) and is represented by ‘weights’ in the logic table.

This captures the ‘judgment’ and ‘trade-off’ aspects of the decision-making process. And it turns out that modern LLMs understand this extremely well. So we can replace pages of IF-THEN-ELSE rules with a single 6-part table structure (given as markdown).

image
image1119×802 217 KB

(1) PARAMETERS “P”
The complete set of input parameters is provided with their name, units, and values.

(2) CONDITIONS “C”
A set of conditions that are used to analyze the combinations of parameters.

(3) RULES “R”
A matrix of formulas that compute the contribution each parameter (P) makes to the ‘truthiness’ of the condition (C).

(4) WEIGHTS (Fuzzy Logic) “F”
The result of accumulating the weights for each condition (C).
0% => condition is FALSE, 100% => TRUE, other values => probability or weight of truthiness

(5) TRIGGER MATRIX “T”
A matrix of weights that determines how combinations of conditions (C) contribute to the triggering of each of the actions (A)

(6) ACTIONS “A”
A list of the resulting actions (A) that are to be triggered by the combination of weights in the Trigger Matrix (T). The highest scoring action (A’) is the result of the process.

This format is easily understood by the human experts designing the process and is also understandable by the LLM.

3 Likes
7

To illustrate this Fuzzy Logic and Decision Tables in action, here is an extract from the AI Log where it found a problem with the pump configuration proposad by the Agent because (as it said itself)…

Shaft seal incompatible — PE-C30 slurry shaft requires TR-3 housing.

and

TR-2 pressure rating insufficient for C30 discharge characteristics.

It then re-evaluated the next-best option and found that it was valid.

Compatibility matrix read. Checking combination: HR-300 + PE-C30 + TR-2.

Found row: HR-300 / PE-C30 / TR-2 → Legal = No — 
"Shaft seal incompatible — PE-C30 slurry shaft requires TR-3 housing. 
TR-2 pressure rating insufficient for C30 discharge characteristics."

Creating Validation Result as Illegal, then logging.
Re-evaluating Tailrace with TR-2 excluded. 
Parameters: 
statichead=75, 
solidcontent=12, 
fluidtype=Abrasive, 
particlesize=0.5mm, 
excluded=TR-2.
Scanning DT Tailrace rows (already in memory):
Static 0–60, SolidContent<=5, Any → TR-1 (solidcontent=12, fails)
Static 60–120, SolidContent<=15, Non-abrasive → TR-2 (excluded)
Static 60–120, SolidContent<=15, Abrasive → TR-2 (excluded)
Static 0–99999, SolidContent<=100, Any → TR-3 (matches, not excluded)
Static 0–60, SolidContent<=15, Any → TR-2 (excluded, and head=75 out of range)
Best non-excluded match: TR-3 (Full slurry-rated discharge).

Updating rows
Tailrace updated to TR-3. Logging and re-running ValidateCompatibility.
Checking compatibility matrix for HR-300 + PE-C30 + TR-3 (already in memory): 
Legal = Yes — "Correct full abrasive configuration."
2 Likes