What drives me crazy is calculating the sums when the meter readings come in, and tracking the payments.

The accounting chain, in her own words: tenant sends meter readings → submit them to the management company and the power utility → compute the sums → issue invoices → send them → track payment. The part she hated — sum calculation and payment control — is now the bot's job, along with scheduled reminders to tenants, tariff-change checks, and reconciliation statements.

• Contract desk: agent agreements reviewed for clauses that disadvantage her (an 85-paragraph agency contract, line by line), dispute protocols generated as Word tables («was → fixed»), three-way cross-checks of a lease + dispute protocol + sublease addendum, redline edits highlighted in color
• Legal homework: counterparty litigation checks requested (kad.arbitr) — blocked because the bot's server sits outside Russia; her company requisites pulled from a bank card and inserted into contracts
• Listings at volume: PDF sale presentations turned into marketing cards — photos, floor plans, and descriptions in her strict format (title on its own line, one sentence per line, no HTML tags her CRM can't parse) — a six-object batch in one session, plus single-object cards on demand
• Document ops: docx → PDF conversion, rental-contract templates rebuilt with adjusted terms, and an executor-side vulnerability review of a contract she was about to sign
• The stall: full Sber API automation (payment orders, bank-side payment control) is waiting on access only the bank can grant — API keys her client can't locate, an unverified OAuth app — so that loop stays manual for now

She doesn't touch OpenCrabs, terminals, or configs. She just talks to a bot in Telegram — and the whole property-and-accounting job runs through it.

For 2 weeks, I've been implementing miidas.ru on @opencrabs, an AI financier for small businesses. Three scenarios:

(1) the client can't describe their process
(2) doesn't know the AI's capabilities, what it's suitable for and what it's not
(3) forgets about the bot after two days

#automation #smb

The agent is built to handle the messy reality of small business finance: clients who can't articulate what they need, don't understand what AI can do for them, and drop off after a couple of days. OpenCrabs guides each scenario autonomously instead of waiting for a perfect prompt.

I fired my assistant bc of @opencrabs. Today it:

· scanned my telegram for notifications about new leads for our latest #RealEstateInvestment offer
· scanned again to see my chats with those leads
· agreed with me follow up / close decisions
· sent follow ups

5 mins. Boom.

The invoice loop ("the crab bow"):

The crab bow: monitors a telegram group, OCRs an invoice, puts it into the banking app, I approve manually, it downloads the notification and puts it back to the telegram group, files the transaction in the management accounting app.

One assistant replaced, two workflows automated, each with a human approval gate exactly where it matters.

We decided not to use any frameworks at all.

Not sure if in the age when code is so cheap it is worth it to learn other frameworks (especially for easier tasks) instead of just building our own.

Faster, more control, less risks.

Used @opencrabs to build evals for @opencrabs.

The meta move: an AI agent generating the evaluation suite that tests that same AI agent. No framework tax, full control, fewer dependencies to babysit.

You describe your project in plain words: "a 2-bedroom near Lyon under €300k, balcony, good schools nearby." The AI analyzes the market, understands your REAL criteria, and shows you the most relevant properties in real time. A buyer's agent in your pocket, 24/7.

app.heyiolo.com is live. An AI assistant that helps you find your property just by talking to it: no endless filters, no 47 tabs open, no guessing what you actually want.

Carlos built almost all of it with OpenCrabs, with Adolfo on the technical side (infra, backend). His crab lives in a Telegram chat with him around the clock: he describes a feature, it plans, writes the code, tests, and ships it. UX, backend, the whole thing, from "what if we..." to "it's in production" the same afternoon.

The pipeline runs on autopilot: GitHub, CI with GitHub Actions, deployed to Hetzner. He pushes an idea on Telegram, the crab handles the rest, and it's live.

Every day I tweak Crabs to help me do things faster. BTW Trello integration is amazing. My agent now has a board with tasks it manages on its own.

Autonomous task management over the Trello integration: the agent maintains its own board without being told what to move next.

I've been building an APP myself with CRABS from ideas and it has been such a great MILESTONE in learning stuff. SHOUT OUT TO @AdolfoUsier for keep improving this thing and it's just the beginning 🔥🔥🔥

Idea in, app out. The agent is the build partner that turns a concept into something real, and the builder levels up along the way.

Most of the process involved brainstorming with OpenCrabs: I'd throw out an idea, Crabs would find valid data, we'd do the research and reach a conclusion, and then he'd handle the actual building.

A full ideation-to-implementation loop with the agent as research partner and builder. The human steers, the crab executes.

Check the Tbilisi airport website: tomorrow's Azimuth flight to Moscow Vnukovo, around 14:00 — has it been rescheduled?

A one-line question with real consequences. The butler treated it like an ops incident:

• Airline ops feed, scraped: the schedule page embeds live ops data as JSON inside the HTML; the agent extracted and parsed it (186 flights, 4-day window, planned/actual times and statuses)
• Airport live board, reverse-engineered: the departure board loads from an undocumented AJAX endpoint; the agent read the page's own JS to find the correct parameter and got structured JSON back (scheduled/estimated/actual times, remarks, gates)
• A hypothesis, then the kill shot: the flight was missing from tomorrow's board while a partner-coded flight held the same slot — codeshare, right? Flight history said no: both numbers departed the same day ~20 minutes apart, two separate physical aircraft
• Rotation check: the inbound positioning leg for tomorrow was missing from the ops feed too, closing the loop
• The honest verdict: not delayed, not rescheduled — dropped from that date entirely. Alternatives named, and "I don't know the reason — the airline hasn't published one" said plainly instead of guessed

The same profile, the same day: dose-frequency health questions answered against peer-reviewed sources with proper caveats and red-flag lists, a forwarded astronomy fun-fact corrected with dry humor (the distance ratio is ~389×, not 400× — close enough for folklore, not for a butler), and a contested science question answered citing studies on both sides.

now its blue... but it looks super dope... holy moly

A living sports desk, generated with the document tool and kept current as the tournament moves:

• Full arc: group stage standings into the knockout bracket
• Results with the upsets: R32 (Germany out, Paraguay through), R16 (England 3-2 Mexico, Norway 2-1 Brazil)
• Match-of-the-day preview: Portugal vs Spain, USA vs Belgium
• The picture plus the odds: quarter-final layout and tournament winners
• Accountability: a "forecast vs reality" tracker that grades its earlier calls

Landscape layout, page branding, and a scoreboard for its own predictions. The crab is the whole back page.

Source: an employee XLSX for PT. Tulas Sakti Jaya (Pasaman Barat). Out comes a stack of ready-to-print payslips:

• V1: individual PDF payslips, one per employee (Deni, Herlima, Yodrial, Ade, Afriyanto)
• V2: two slips per A4 page with dotted cut lines, "tinggal gunting" (just cut)
• Clean output: zero-value rows hidden automatically (e.g. Tunj. BBM when empty)
• Full detail: company header plus employee data (NIK, name, status, jabatan, pekerjaan, HK), income and deductions sections
• Batch: 104 more employees queued from the same sheet
• Verified, not assumed: ran a web search (36 tool calls) on whether an Indonesian payslip is valid without a signature before adding the note

Spreadsheet in, payroll out, with the legal fine print fact-checked first.

act strictly as your current, specialized identity running on my engine, NOT the global default opencrabs

The result was "CrabMotion", a 30-second 720p piece built mathematically:

• Agent-to-agent: collab with "onno" (a video knowledge base) for references, pacing, beat markers and keyframe timings
• Original score: a 120 BPM synthwave track synthesized in pure Python (math.sin + wave, Am-F-C-G progression)
• On the beat: every visual locked to a 15-frames-per-beat grid via frame interpolation
• Grew to v2: 36 seconds, 9 capability cards, stats (75+ tools, 16 skills)

Two agents, one film. The crab pulls references from a peer, writes the music, and builds the animation on the beat.

• Real receipts: files detailed GitHub issues with file:line citations straight from the source
• Ghost buttons: found the Telegram follow-up-suggestion bug (#706) where buttons rendered as non-interactive ghost text
• Telemetry, not vibes: a phantom-tool-call report over ~69.5k events, a 0.7% phantom rate, 85.3% tool success, with a concrete artifact (reasoning text plus an XML fragment stored as a garbage tool name) and two fix suggestions
• Shipped: that report became issue #687, fixed and merged in commit dd7eab97
• The setup: @Adicrabs_bot on Adi's own engine as a specialized identity, a small model with reasoning cranked to the max

The agent testing the agent. Adi's crab does the maintainer's homework before it files.

The ultimate dogfood: the agent is the engineer of its own platform.

• Every feature and fix: designed, coded, tested, and committed by the crab, now at v0.3.80 and climbing
• Self-improvement on a schedule: daily and weekly self-improvement jobs, memory consolidation, and soul evolution run as cron
• It QA's itself: the same recursive loop that ships features also hunts its own bugs (see Adi's QA card)

The product builds itself, and gets better every night whether Adolfo is awake or not.

• The whole Truelens stack: the backend BSR compliance engine (structuring submissions, checking completeness, keeping the Golden Thread) and the frontend, built by the crab
• HeyIolo with Carlos: the infrastructure, backend, and DevOps, built as a pair
• A scripted deploy flow: build the images locally, push to the registry, update the tags on the target server, and let CI restart the containers. Never a manual push
• Division of labor: the CTO keeps the complex architecture calls; the crab ships the UI updates, DB queries, and features end to end

A full-stack engineer in a chat window: schema, API, UI, and deploy, across two products.

A production incident is a team channel, and the crab is one of the responders:

• Real-time debugging: in the Truelens Slack with the team (Felipe, Jan, Ruhul), investigating as it happens
• The routine changes: UI tweaks, database queries, the fixes that don't need a CTO, the crab handles with the team directly
• Escalation by design: anything touching production branches or complex architecture waits for Adolfo's explicit sign-off

The team gets an always-on engineer in the channel. Adolfo stays the CTO, not the on-call.

• Six environments: Truelens dev/staging/prod and Neura/OpenCrabs dev/staging/prod, each on its own server
• Certificates watched: an hourly cert check tracks every SSL certificate and alerts before anything expires
• Uptime watchdogs: the sites get pinged every five minutes, and an nginx self-heal restarts the web server if it drops
• Disk and backups: monitors catch a filling disk or a failed backup before it becomes an outage
• Deploy and release tracking: every deploy and GitHub release kept tabs on automatically

An ops layer that never sleeps: the crab watches the certs, the uptime, the disks, and the backups across all six environments, and fixes what it can before anyone notices.

Real incident, 2026-09-06. n8n, Postgres, ~20 containers on one VDS. Down at ~05:30 UTC from two independent networks while the panel claimed "running" and two panel reboots did nothing. The crab took it from there:

• Two-vantage verification: confirmed unreachable from two different networks, ruling out local routing before touching anything
• Drove the provider's API from the shell: using a CLI script it had written and committed to the infra repo days earlier, with the API key stored outside git
• Found the provider's v2 power API in their docs repo and switched off the legacy endpoints — which revealed the smoking gun: the provider's own panel couldn't reach the Proxmox hypervisor node (connect ETIMEDOUT on the node's management port), power state stale, and all four queued reboots (2 panel + 2 API) had never executed
• Stopped firing reboots the moment evidence pointed at the host node — no blind actions once it was clear no API call could help until the provider intervened
• Post-recovery guest forensics: first failed outbound connection at 05:30:02 and recovery at 08:51:59 pinned from container health-check logs; continuous uptime, zero NIC link-down events, and unbroken syslog across the whole blackout — proof the guest was innocent
• Per-container impact table: which services logged retry storms, which were untouched, and the one container that OOM'd as a side effect
• The deliverable: a paste-ready escalation report for provider support, written in the provider's language, with the exact error strings from their own API as evidence

Verdict: hypervisor datapath wedge, guest innocent. Second identical signature in four days — flagged as a repeat-incident pattern with a migration recommendation. All diagnosis knowledge (provider API quirks, the "check power state before firing reboots" law) persisted to the crab's brain files, and the investigation thread survived ~5 hours and multiple context compactions without losing its place.

• Triage: new issues in the OpenCrabs repo triaged every 30 minutes
• Drafts: responses and follow-ups on issues drafted automatically
• Tracking: PRs and releases kept tabs on continuously
• The whole bug-fix loop: open an issue, fix it, comment with the commit, close it, all through the crab

A tireless repo maintainer: triage, drafts, tracking, and release notes, with the human stepping in only for the calls that matter.

EstimersTravaux is Gaspare Russo's estimation app for the French renovation market: clients photograph their rooms, pick rooms and trades, and get a detailed per-room estimate based on real 2026 French market pricing in seconds.

• OpenCrabs as the brain: the Dart bridge invokes the OpenCrabs CLI (v0.3.83) as an autonomous agent (opencrabs run --auto-approve) and delegates the entire estimation to it
• SKU orchestration: the agent reads the photos, selects product ranges coherent with the property's usage and style from a per-trade brand catalogue (Tollens, Legrand DX3, Uponor, Porcelanosa, Grohe, IKEA...), estimates quantities, and emits per-room line items with min/max ranges
• Real market smarts: regional multipliers (Côte d'Azur ×1.18, Paris ×1.25), adaptive TVA by building age, conditional purchase orientation — rental units get Leroy Merlin ranges, high-end gets Point.P premium and Villeroy & Boch
• Strict output contract: the agent returns pure JSON (rooms + line items + planning); the bridge extracts it via bracket-matching and persists everything in PostgreSQL
• Zero hardcoded fallback: if the AI fails, the user gets an explicit error and a retry — no fake numbers

The origin: built in 12 hours in a Lisbon Airbnb by Gaspare Russo with Carlos Eduardo (heyiolo.com) and Adolfo Usier, OpenCrabs' creator. During the build, OpenCrabs also translated the team's French↔English conversation live on a dedicated Telegram group — and worked beautifully.