OpenClaw Meetup #1
April 6, 2026 | Seattle, WA
Note: This document is reconstructed from a speech-to-text transcript. Speaker names, technical terms, and product names may be approximate due to transcription artifacts. Ambiguous passages are preserved as-is and marked with [unclear] where meaning could not be confidently reconstructed.
Opening & Host Session
Speaker: John Kennedy, Founder of Actual AI
Audience Poll
John opened with a series of show-of-hands polls:
- Who has used OpenCore before? Most of the room.
- Who has built a skill? Many hands.
- Who has scheduled a recurring task? Common use case, many hands.
- Who has tried other agents (e.g., OpenFang)? About five people.
One audience member explained they use another agent because they built their own for their organization. John echoed this: "Same story here -- built my own for my organization. We have other alternatives. That's why I have an entire suite of agents."
A few attendees have given their agents permission to write emails and manage calendars on their behalf. John called them "the brave people." One attendee mentioned issues connecting to Gmail -- the labeling system didn't transfer properly. John noted it has automatic deployment of new features ("you press a button and it'll be quick -- well, ish") and mentioned a dashboard, possibly called Paperclip [unclear].
Token Cost Discussion
An audience member named Chia asked about token cost concerns. John polled the room:
- Who is using OpenAI? Several hands.
- Who is using Codex? A few people. (John noted they personally stopped using Codex.)
- Other models were mentioned but responses were inaudible.
Chia also later asked why John was still using Sonnet 4.5 and whether they had tried Opus with the one-million-token context window, and what model the CFO (discussed below) was using.
Actual AI's Agent Infrastructure
John described their deployment setup:
- They run multiple OpenClaw instances, deploying them quickly for testing purposes -- "boot up one quickly and then cut it down again."
- All agents are connected via TailScale, which John strongly recommended: "If you're not using TailScale -- it's a very convenient security mechanism to connect your [agents] so you can connect to them directly and take them off the public internet."
- They have a dashboard for monitoring.
- They deploy via Kubernetes, both SaaS and on-prem.
- They still have a [unclear] dashboard and run sub-accounts to deploy systems.
Open questions John flagged:
- Can they use different models effectively?
- Can they share memory between agents? "If anyone has a really good shared memory system -- we're using kind of local knowledge bases at the moment -- but if anyone's cracked that code, there's lots of good stuff."
Actual AI — John's Company & Products
John's company builds agents as its core product:
- Two main agents: an architect agent and a manager agent.
- The architect agent helps generate and agree to architectural rules; the manager agent gives visibility over processes.
- These run in SaaS, on-prem, and via Kubernetes.
- John noted: "It's all natural to start building out capabilities with agents rather than internal apps. In the past we built internal SaaS apps, but we have agents that are tools that make sense."
- Their partner manager is non-technical but excels at using OpenCore -- "you can have non-builders or non-coders build. That's been really great to see."
Named Agent Architecture (Agent-as-Person Model)
John detailed how they map agents to specific people and roles:
| Agent Name | Role/Function | Platform |
|---|---|---|
| OJ | Chief of Staff agent (named after employee Olivia, whose last name starts with OJ) | Slack |
| Kevin | John's personal agent -- product, SEO, backup planning, future prioritization, epic management | Not yet on Slack |
| Partner Paul | Gathers partnership opportunities from ADEO, researches new opportunities on the internet, generates weekly partner activity reports | [unclear] |
| Austin | [Function not specified] | Not yet on Slack |
| Pennyworth | [Function not specified] | Not yet on Slack |
| Lucas | [Function not specified] | Not yet on Slack |
Anecdote about OJ: "We went through this whole thing on Slack with OJ where we started saying, 'You know, it's great that you're a football player, OJ,' and how things have been -- and OJ got really frustrated with us, like, 'I'm not OJ, I'm just looking forward!'"
John's rationale for this approach: "When you map to a person and look forward to a goal, it helps you think about the bucket of functions you want to put in there."
Data Siloing & Security
Key design principle: no single agent has complete access to everything. Each agent operates in its own data silo.
- Partner Paul has access to partnership data and internet research but doesn't touch Jira.
- Kevin interacts directly with Jira.
- "Data siloing helps with security and risk mitigation."
The CFO Story (Automated Monthly Closings)
John recounted a call from a few weeks prior with a CFO who built an agent framework:
- Data sources: ERP, Google Drive, QuickBooks, bank accounts.
- What it does: Reconciles data from ERP, bank, and Drive. Creates transactions directly in QuickBooks. Fully automates monthly closings -- no manual work.
- The CFO's business is an artisanal manufacturer with particular/custom orders, which makes reconciliation complex.
- He built his own dashboard for monitoring.
- John's reaction: "Holy shit, that's really dangerous." But the CFO "knows how to do checks and balances against that."
- Key takeaway: "You have to have secondary systems checking on the outcomes."
Presentation 1: AI for Agriculture
Speaker: Oleksandr Tereshchuk
Background
Oleksandr comes from an environmental/finance background -- recently explored agriculture after visiting Thurston Opportunities Bank [unclear]. He noted that agriculture is "not so much penetrated by AI yet, and there are reasons."
He has visited farms across multiple locations:
- Las Vegas, Kansas, Michigan
- Fraser Valley, Canada
- A farm with 25,000 cows
The Problem
- Data is fragmented. Farmers (or family management offices) use 7 to 10 different systems. "Nothing talks to each other."
- Operations don't talk to finances -- this is a major problem.
- People spend hours every day navigating disconnected systems.
The Project
Started: Valentine's Day 2026 (February 14). Eight-day sprint. 19-hour days.
Core question: Can OpenClaw collect all this scattered data without formal integration, without APIs? "Because if I could do that, those companies probably wouldn't have to retake their data structure."
Current deployment: A 480-cow dairy farm in Canada.
Architecture
Data sources (left side of his diagram):
- Milk production data
- Animal health
- Agronomy
- Operations management
- Pharmacy
Financial data (right side):
- Financial systems (separate from operational)
Five collectors built:
- Piping collectors running as OpenCore scheduled tasks
- Pull from: server-based systems, websites, manual documents
- Schedule: Some run 3x/day, some run 1x/day
- Data flows into a local data layer pipeline: collect -> normalize -> store -> query via LLM
Normalization method:
- Data stored in a folder tree on OpenClaw
- Python scripts convert everything to JSON files via raw parsing
- Works well for text and CSV files
- PDFs: less ideal, but manageable -- he keeps relevant pages, removes irrelevant ones, and parses them
Infrastructure:
- Installed a UPS on the farm because of frequent power swings
- Using Discord personally; farmer uses WhatsApp
- LLM providers: primarily OpenAI, Gemini, and Codex via the O1 application
Key Insight: WhatsApp as Interface
"Having WhatsApp is a huge deal for farmers."
Farmers went from never asking analytical questions (because it would take hours of system navigation) to asking daily via WhatsApp. The barrier reduction was transformative.
Example questions farmers now ask:
- Which are the top and bottom performing cows?
- How many cows died last week?
- How much did it cost us?
- How many liters of milk were produced this week vs. last week or last month?
Capabilities Demonstrated
- Data absorption from scattered sources
- Cross-referencing with external data (e.g., milk prices) to calculate revenue/costs
- Evidence-backed statements -- every response references a source report
- Cross-role communication -- information shared among any role on the farm
- Custom alerts
- Proactive report generation -- the farmer gets a daily morning briefing with bullet points alongside coffee/tea
Guardrails Against Hallucination
When asked how he ensures the system doesn't invent answers:
- The system only queries normalized local files -- it doesn't search the internet for answers
- "It just moves to my normalized files and just moves around a file"
Data Locality Caveat
While the data is stored locally on the farm, it is sent to cloud LLMs in normalized form for inference. "I cannot 100% claim it's local -- it never leaves the farm -- but we can do it by deploying a local model once we have a proper use case for it. I don't even know what kind of model we need yet."
Future Vision: The Farm Digital Twin
Next steps: Create a world model of the farm with dedicated sub-agents mapped to existing farm roles.
- The farmer already has humans doing these jobs -- the plan is to first supplement these roles with AI agents, then gradually take work off their plates entirely.
Ultimate vision: "Farm in a Box"
- Every farm has intelligence installed on a physical box on-site
- A digital twin of the farm
- Capable of advising, scheduling tasks, data analysis
Q&A
Q: How do you make sure it doesn't invent answers? (High-stakes context -- this is the farm owner making financial decisions.) A: It only answers from normalized local files. It doesn't search externally.
Q: How are you normalizing data from different sources? A: Folder tree structure, Python scripts converting to JSON via raw parsing. Text and CSV work well. PDFs require page filtering before parsing.
Presentation 2: CloudMap - Team Memory for Coding Agents
Speaker: Xin Shi (from a database company, building CloudMap)
The Problem
Many open source memory solutions exist, but they lack:
- Scalable structure and storage
- Cross-team sharing capability
Product Overview: CloudMap
CloudMap is a plugin for OpenClaw (and presumably other coding agents) that provides persistent team memory.
How it works:
- Install the plugin and skills
- Talk to the coding agent normally
- CloudMap handles everything in the backend
What gets stored:
- All conversations with coding agents
- Skills learned
- Lessons learned (explicitly forced by the engineer or automatically captured)
- Design principles
- Facts about the system
Cross-team queries -- the core value proposition:
- Example: Engineer Alice tells her coding agent something. Later, engineer Bob can ask the memory system: "What was Alice doing? What has Alice learned? Why did she make these design decisions?"
Live Demo
The speaker showed a management console for a code repository with five engineers working:
Visualization:
- A node graph showing all conversations and events happening in the system
- Each node is inspectable for details
- Access management, team management, and organization management controls available
Demo Query 1: "What did others do to our backend system yesterday?"
- The speaker, a product manager, asked this despite not knowing kernel-level techniques
- OpenClaw with the ClawMap plugin responded with:
- An engineer with alias Ian Rheel had made changes
- The CEO had changed a few features
- A high-level summary of all changes
Demo Query 2: "What has this principal engineer learned from building this project?"
- The system captured all conversations, automatically embedded them, and learned from the semantic content
- Conversations are condensed over time into: skills, lessons, design principles, facts
- For this engineer, the main pain points were overhead in the database -- algorithms and database design
- CloudMap summarized high-level lessons and specific database insights
- Use case: someone backfilling or taking over from this engineer can instantly spin up an OpenClaw instance that inherits all skills, memories, and conversations to continue the work
Architecture
- Built on top of their own database (the company is a database company -- natural dogfooding)
- Uses GitHub REST APIs as part of the backend -- leveraging the fact that coding agents already know how to use Git issues and repositories to organize data
- Search: Hybrid search with built-in embedding generation
Storage Format
- "Everything is a file, like in Linux systems."
- Skills are Markdown files in the file system
- Cross-organization sharing is possible depending on permission configuration
Getting Started
- Free service (fully serverless)
- Website built using OpenClaw
- Install via a prompt, and it auto-installs the plugin
Q&A
Q: Are you looking at adding "dreaming" -- the idea of memory decay? A: "Exactly, yeah. There are tons of interesting things. Dreaming is one of those." They are currently experimenting with emotions first -- detecting engineer emotional states from conversations to flag burnout/mental health issues. "We really care about people's mental health. We are adding emotions, and probably dreaming in the future, so that we can invite our HR team to really take care of and protect all the employees in this AI-native era."
Q: Do you have a common format for memories? Can you convert a memory to a skill and share it with someone who doesn't have the same structure? A: Yes. Everything is file-based (Linux-like design principle). Skills are Markdown files. Sharing across organizations is supported with permission controls.
Q: How do you handle noise at scale? Right now it's 4-5 people -- what about 100+? A: Two aspects:
- Role-based access control based on real organizational structure. As more people join, they work on different functions and need scoped access.
- Gradual retirement mechanism. Over time, old conversations and features accumulate. They are building systems to abstract these into design principles and real facts, filtering out noise. When a new team member starts working in an existing domain, they get the distilled knowledge, not the raw conversation history.
Presentation 3: CodePatent Scanner
Speaker: Lee Brown
Background & Motivation
Lee Brown has been researching AI's impact on software engineering for about a year and a half. His key observation:
Development workflows are changing. Traditionally: product/marketing team creates specs -> engineers develop. Now: "We're all vibe-coding. And as we're vibe-coding, our product documentation is the code."
The problem: Engineers are coding so fast that they don't capture what they've actually developed. Novel inventions get lost in the velocity.
The patent problem: Filing patents requires pausing work, finding a patent lawyer, and going through a lengthy process. But provisional patents don't require a lawyer and can be done entirely with an LLM.
Product: Four OpenClaw Skills
Available on ClawHub (open source, free):
- CodePatent Scanner -- Scans a codebase and identifies novel inventions
- CodePatent Validator -- Searches the internet for relevant prior art and compares against findings
- Two additional skills (not named in the transcript)
Why skills, not a SaaS product? "The biggest issue is: you guys are developing your own IP." OpenClaw's value is the transfer of responsibility from cloud to private. Users can run these skills with whatever LLM they're comfortable with, without uploading code to an external API.
How the Scanner Works
Input: A code repository (or subdirectory of one).
Process:
- Scan the codebase
- Compress the code down to core principles (not detailed code analysis)
- Score the principles on four dimensions
- Generate a problem statement and solution description
The Four Scoring Dimensions
-
Distinctiveness -- How unique the approach is compared to standard/common approaches.
-
Sophistication -- The level of engineering complexity applied to the challenge.
-
System Impact -- If you took this design pattern and applied it to another project, how much impact would it have? (Transferability/generalizability.)
-
Frame Shift -- "This is the one that really pushes the novelty of an idea." If everyone is thinking the same thing, someone has probably already thought of it. Frame Shift measures: what change in perspective has the human developer applied that is different from everyone else? "That's a lot of times what the human is bringing to the table, not necessarily the LLM that's been trained."
The Compression Insight
From conversations with patent lawyers:
- Patent lawyers don't like scanning codebases for patent filing purposes.
- If they know all the implementation details, the filed patent becomes too specific and thus too narrow.
- The CodePatent Scanner mimics this: it acts as a compression algorithm.
codebase -> core principles -> novelty analysis
Live Demo: Scanning OpenClaw's Security Module
The speaker demonstrated scanning the OpenClaw repository's source security directory.
Result: Novelty score of 12 out of 13.
Finding: "A prompt injection defense system that generates per-message cryptographic boundary markers -- random bytes -- and applies multi-layered Unicode normalization before checking if an incoming content attempts to spoof those markers."
Output structure:
- Description
- Problem statement
- Solution description
- Benefit
- Score (per dimension)
- Claim angles (suggested patent claim formulations)
The scanner also found four patent concepts from the OpenClaw codebase overall.
Provisional Patents as Stock Options
Lee Brown frames provisional patents as financial options:
- File a provisional patent using the scanner's output (minimal cost, no lawyer required)
- Get 9 months to evaluate whether to pursue it
- Then 3 months to work with a patent attorney or file yourself
- "Basically a stock option" on your IP
Motivation: Leveling the Playing Field
"OpenClaw is changing really fast, and there's this asymmetry -- if you have capital, everybody else is kind of running ahead. We're hoping that if smaller teams get the opportunity to patent some of their ideas, then hopefully we can continue to still have level playing fields."
Q&A
Q: Does each scan start from a clean slate, or is there state management? A: Currently clean slate every time. But they want to add scheduling -- overnight scans in a "dream state" mode. "Scan your codebase at night, and in the morning when you wake up, you can see potentially your novel ideas." Not yet implemented but actively being worked on.
Q: Could this be used to evaluate engineering talent? A: "Yeah, totally. We could totally do that. If you want to build that as a side project, let's do it."
Presentation 4: Lucas Brown
Speaker: Lucas Brown
Notes were not captured for this presentation.
Presentation 5: Azure Agent Orchestration Service
Speaker: Johnson Shi, PM at Microsoft
Caveat stated by the speaker: "Everything I'm mentioning here is still exploratory."
Vision: Agents as Digital Vendors
The speaker and his colleague Pao frame agents differently from most:
- Not software tools -- digital vendors/contractors.
- "You're not hiring just a tool to run a bash script or a CLI command. You're hiring a digital twin to start with, and then later on you're going to be hiring an org chart."
- TAM (Total Addressable Market): Not just the software market -- it's the outsourcing and vendor services market, and potentially the whole labor market.
The Mental Model Shift
| Old Thinking | New Thinking |
|---|---|
| Install OpenClaw | Hire an OpenClaw companion |
| Add compute | Expand your agent workforce |
| Check dashboards | Do agent employee performance reviews |
| Configure ACLs / identity management | Use an agentic HR management system |
Sub-agents can be ephemeral or permanent. You build an org chart of agents.
Example Scenario: Cross-Border Business Expansion
A Bulgarian fitness supply company wants to expand to Poland. Two blockers:
- Marketing people (labor)
- Marketing productivity tools (software)
The SaaS era solved #2 -- companies can buy Salesforce, HubSpot, Workday. They could also build their own stack on PaaS/IaaS. But companies are still blocked on #1 -- the labor problem.
"For the first time, business opportunity -- national GDPs as well as business market cap -- is decoupled from human labor."
The Envisioned Stack
Enterprises/SMBs hire agentic work vendors -- these vendors are hosted on Azure Cloud (or equivalent), which provides:
Layer 1: IaaS -- Kubernetes, VMs, Azure AI Foundry
Layer 2: PaaS -- Agent Orchestration (the new offering)
- Agents are managed via Intune or equivalent security suites
Intelligence providers (BYO):
- OpenAI SDK
- Anthropic SDK
- Azure AI Foundry
- Amazon Bedrock
Two On-Ramps
- Managed PaaS service (hosted by Azure)
- Open source tool (self-hosted)
Both aimed at letting startups "focus on your core business logic and do away with managing the infrastructure."
Demo: azure-callup One-Command Deployment
A single CLI command (azure-callup) provisions everything:
- Kubernetes clusters
- Container registries
- Kubernetes credentials
- Federated credentials in Entra Active Directory
- Sandboxes
- Azure AI Foundry / OpenAI Foundry space for agent intelligence
Monitoring: TUI with Mesh Traffic Visibility
A terminal UI (TUI) shows:
- What URLs agents are trying to access
- Which agents are communicating with which other agents
- Agent utilization metrics
- "Mesh traffic visibility is a proxy for how productive your AI agents are, just like how you do performance reviews at work."
Security Architecture: Kubernetes Pod Design
Agents run as containers on Kubernetes. Each pod contains:
| Container | Role |
|---|---|
| Init container (Egress Guard) | Starts first, controls outbound network access |
| Main container (OpenClaw pod) | The actual agent |
| Sidecar: Inference Router | Routes LLM calls to OpenAI, Anthropic SDK, or Azure Foundry |
| Sidecar: Agent Governance Toolkit | Policy enforcement -- allowed/blocked tool lists, endpoint restrictions |
Agent Governance Toolkit
Described as "an Envoy sidecar for agents" (referencing Envoy/Istio service mesh proxies from the Kubernetes ecosystem).
- Evaluates everything the agent tries to do
- Enforces allowed lists and block lists for:
- Tools the agent can use
- Endpoints the agent can access
Call to Action
"If you guys are interested in a one-command, one-line command to spin up a fleet of agents, message Johnson Shi on X."
"We're not trying to compete with you guys. We're trying to power the startups of the future."
Cross-Cutting Themes
-
Local-first with cloud LLM escape hatch -- Multiple speakers emphasized keeping data local while using cloud LLMs for inference, with aspiration to eventually run local models.
-
Agents mapped to human roles -- Both John (named agents per business function) and Oleksandr (farm roles as future agent roles) use this pattern.
-
Memory as unsolved problem -- John explicitly flagged shared memory as unsolved. The CloudMap speaker is building a solution. The patent scanner speaker wants "dreaming" overnight scans.
-
Non-technical users building with agents -- John's partner manager, Oleksandr's farmers via WhatsApp, the CloudMap PM querying engineering knowledge.
-
Secondary verification systems -- John stressed this after the CFO story. Oleksandr constrains answers to normalized local files. The Azure PM's Governance Toolkit enforces policies.
-
Compression over detail -- Lee Brown's patent scanner compresses to principles. CloudMap condenses conversations to skills/lessons. Both fight information overload.
-
The "dreaming" concept -- Came up in both the CloudMap Q&A (memory decay/consolidation) and Lee Brown's Q&A (overnight scheduled scanning). Background processing during idle time.