A breakdown of my real practice: what tasks I solve with Claude beyond code, how my "data lake" is built, how memory works across sessions, what skills and automations I've built, and which techniques make it all work. Everything below is reconstructed from my files, scripts, memory and reports in ~/dev/claude/data.
I use Claude not as a chat, but as an agent-employee with access to a local copy of the entire company — it both answers questions and does the work itself.
All the correspondence, tasks, sales and calls are pulled into one folder on disk. Claude gets access to it through ordinary file tools (Grep, Read, agents) — and so it can answer questions like "what's on fire with clients this week", "how long will feature X really take", "which partners actually bring in money" — citing specific quotes and numbers rather than making it up. And it's not just analytics: with that same access it does the work — it creates and tracks tasks in Notion, answers the team's questions, writes messages on my behalf, works in our CRM, changes settings in systems and runs automations.
Three things make this powerful: (1) data is local — I don't depend on API limits and can instantly search the entire mass of correspondence; (2) memory survives sessions — Claude remembers my rules and past conclusions; (3) the result goes where the team works — a report flies straight into the chat instead of staying in the terminal.
The architecture below is a consequence. These are the principles it rests on. Most of them I voiced while explaining the system to another founder; I've gathered the most important here.
The main constraint isn't the model — it's the speed at which your brain adapts. You can't outrun it. So the first goal is simply to spend as many hours with it as possible, until your habits rewire and the new way of working becomes reflex. Everything else in this guide is about what you start doing once that rewiring is underway.
The main mental shift. You describe the desired state, not the way to reach it. I don't even know where my script that downloads chats lives or which cron entry runs it — and that's fine: I described the result ("so the chats are always downloaded"), not the plumbing.
Any LLM is a statistical model: it gives you the average of what it has read. For 95% of tasks the average is enough — the result is no worse than what an employee would do. But for the 5% (strategy, marketing, creative) the average isn't enough — there you need to add your own context: your framing, your logic, what matters specifically to you.
A corollary of 95/5. Where you need to come up with something good — that's still expert work. An example from code: how authorization is implemented in the CRM — I don't care, "it's there somehow and it works." But the architectural relationship between entities — that's mine, that's where I add context and think for myself. This isn't "not for strategy": with your framing and context it works through strategic memos beautifully (examples are in the "What tasks" section) — you just set the direction, not it on its own.
It's not dumb — but out of the box it doesn't know you or your business. Explain things the way you'd explain them to a sharp new hire. You don't need to write tiny over-specific rules "for every little thing" — you need clearly delivered context.
When I wrote my own agent from scratch, it became obvious: 90% of the result is giving the model the right context and the right tools it can use to enrich that context itself. The data lake, memory and skills below are all machinery aimed at one goal: deliver the right context at the right moment.
Repetitive things shouldn't be done on request — ask it to write a script and put it in cron. Then the data is always fresh, without burning tokens, and at work time the agent just takes what's ready.
Bolting neural nets onto an existing process is a crutch, it gives ×3–×5 to productivity. Reinventing the process from scratch, now that everything is different, gives ×100. So the biggest chunks of value are born not in "optimizing what was" but in "what would this look like if we built it anew."
If you program even a little, spend a day and write the simplest agent yourself. Any modern agent is a loop: a request to the LLM → a tool call → the next request to the LLM, and so on until the task is solved. Once you write it by hand, you'll understand far more deeply what to expect from an agent in different situations.
The range is almost the entire non-technical management of the company. Below it's grouped by type of work, with real examples from data/reports/.
| Category | What Claude does | Real artifacts |
|---|---|---|
| Actions in systems, not just reading | Not just an analyst: creates and tracks tasks in Notion, answers the team's questions, works in our CRM, changes settings in admin panels and systems, writes and sends messages — does the work, not just reports on it | skills notion-tasks, write-as-me + telegram-send, project-setup |
| Parsing correspondence → conflicts | Scans client chats, finds escalations, bugs, churn threats, "stuck" items; cross-references with the client's GMV and prioritizes | daily/*.txt, <client>_chat_analysis, <client>_conflict_analysis |
| Estimating dev tasks | Reads repository code and produces a spec + an estimate in days, looking for the cheapest path through existing mechanisms. A bridge between business and dev | skill estimate-task, client integration estimates, starter_blocks_roadmap |
| Sales and revenue analytics | Pulls Redash/AmoCRM, computes GMV, manager commissions, cohorts, dynamics by country | sales_analytics, sales_deep_analytics, sales/redash/* |
| Partner program | Stitches together 3 incompatible accounting systems (Notion ∪ Telegram ∪ Amo), computes the real top partners, conversion, deal cycle | partner_program_analysis, partner_analysis/union.json (all partners as one dataset) |
| Team and processes | Summary overviews of workflows and workload, prep for 1-1 meetings and retrospectives | internal team summaries |
| Product and priorities | Consolidates client wishes, hypotheses, tickets, the roadmap of paid improvements | product_priorities, autopilot_wishes, notion/bugs_features/* |
| Launches and processes | Analysis of the client onboarding process, empathy in launch chats, automating the routine | launch_process_analysis_2026, launch_empathy_automation_2026 |
| Strategy and research | Strategic memos (the AI era, software commoditization), chronologies of product decisions | strategy_ai_era, software_commoditization_starter_2026, "Cabinet timeline" |
| Testing the AI autopilot | Running the bot's test scenarios, a 3-way comparison of answers on real quotes | testbot_3way_comparison, testbot_real_quotes_* |
| Calls → knowledge | Auto-collecting recordings from all sources → compression → Google Drive → manual upload into NotebookLM | sync_recordings.py, the calls/ folder |
| Communication on my behalf | Drafting and sending messages in my voice, with register tuned to the recipient | skills write-as-me + telegram-send |
| Task management | Takes tasks from the Notion kanban, tracks statuses, closes them — including in an autonomous loop | skill notion-tasks |
Plus personal tasks outside work — Claude is used beyond Starter too (separate folders per project and client). The principle is the same: pull context locally → analyze → get a report.
Everything lives in one folder, ~/dev/claude/data — the "Starter Data Lake." A single README.md describes what's where and how to update it. This is the heart of the system.
telegram/ — hundreds of work chats, each as a flat grep-friendly chat.txt (and where available, the raw messages.json alongside)pachca/ — the internal messenger: channels by department + _users.json (employee registry = source of truth for names)notion/ — database exports: wishes, tickets, paid improvements, hypotheses, sprints, meeting minutes (2021–2026)sales/ — amo/ (leads, contacts, funnels) + redash/ (GMV, commissions, cohorts in JSON)calls/ — call recordings (audio + transcripts)scripts/ — syncers and utilities (Telegram, Pachca, Notion, Amo)insights/ — a fact-extraction pipeline into SQLite (insights.db)reports/ — finished HTML reports + daily/ (daily summaries)research/, sales/, <client>/ — materials on specific topics.secrets/ — a separate protected folder for tokens, outside the code.txt next to .json. Each chat is saved both as structured JSON (for scripts) and as a human-readable chat.txt in the format [date] Author: text — the latter greps perfectly. The daily script literally does grep -E "^\[($DAY0|$DAY1)" across all chats.README.md as a map. Notion database IDs, paths to tokens, sync commands — all in one place, so both I and Claude find things without digging.pachca/_users.json, not guessed from a handle — and that's written both in the README and in memory.A deliberate choice. The model already searches "like code": it finds a line, looks for its occurrences elsewhere, builds up its own context — and it does the same with any text. RAG only gets in the way here: the search runs many times, and when you pull in a document at a time (one, then another, then a third), it slows things down a lot. Flat .txt + grep is faster and more predictable. The one mandatory condition is to convert everything to text: calls → transcript (Whisper, locally, free), rather than stockpiling screenshots that would "eat infinite tokens."
The data lake isn't static. Scripts in scripts/ regularly pull in the new stuff so Claude always works with an up-to-date picture:
| Script | What it pulls | How often |
|---|---|---|
telegram_sync.py / telegram/ | New messages from work Telegram chats (its own sync_telegram.sh + a lock — slow FloodWait catch-ups don't block the other syncs) | every ~15 min |
pachca_sync.py | Pachca channels and DMs + the employee registry | regularly |
amocrm_sync.py | Leads, contacts, notes, funnels from Amo | regularly |
redash_sync.py | Analytics snapshots from Redash (GMV, commissions, cohorts) — a cache of saved queries, with no load on prod | once a day |
notion_*.py | Whole Notion databases + inbox + launcher errors | on request/script |
sync_recordings.py | Call recordings → ffmpeg compression → Google Drive | every 3h (launchd) |
sync_all.sh | An orchestrator of the fast syncs (pachca, amoCRM, redash) under a shared lock and timeouts | cron every 15 min |
The key principle: mirror the data locally first, then analyze. This removes the dependency on API rate limits during the analysis itself and lets me grep everything instantly.
So Claude doesn't start from scratch every session or repeat mistakes, I have three different memory mechanisms — for different horizons.
A plugin that automatically records "observations" about every session (what was explored, what was decided, what was done) into a searchable database. Currently 513k tokens of past work; recall saves ~95% of tokens versus re-reading.
Types: 🔵 discovery · 🟣 feature · ⚖️ decision · 🔴 bugfix. Access via mem-search or get_observations([ID]).
A memory/ folder with a MEMORY.md index and one file per fact. Four types: user (who I am), feedback (how I want it to work), project (current projects), reference (external resources).
This is where my corrections land, so they don't recur. Loaded into the context of every session.
A SQLite database where an LLM pipeline (insights/extract/) extracts typed facts from correspondence: problems, complaints, by client tier and date. The query is query.py top-problems --tier 1 --months 3.
For analytics where you need SQL over the "soft" data of correspondence.
The most valuable technique. When Claude makes a mistake, the correction isn't lost — it becomes a memory file with sections Why (what exactly went wrong, with a date and a fact) and How to apply (a concrete checklist). Examples from my memory:
The effect: the same rakes don't get stepped on twice, and Claude gradually picks up my model of the business and my quality standards.
A skill = a process written down once that Claude picks up by a trigger phrase. I've built 13 of them. This turns "explain it again every time" into "take the next task."
| Skill | Trigger | What it does |
|---|---|---|
| write-as-me communication | "write as me", "reply to X" | A draft in my voice: brief, sentence-case, register tuned to the recipient (client/team/close circle), no swearing or bureaucratese, with the smiley ) |
| telegram-send communication | "drop it in Telegram", "find a chat" | Reading/searching/sending via Telegram. Actual sending, not a draft |
| estimate-task product↔dev | "estimate the task", "how long will it take" | Deep code research → an HTML spec with a baseline, path A/B, a table of files and an estimate in days; separately hunts for the periphery (design, CRM, localization) |
| notion-tasks tasks | "take the next task" | A CLI over the Notion kanban: list / claim / comment / complete. Works in an autonomous loop too |
| notion-download data | you give a Notion link | Downloads the page (+ nested ones) as Markdown for analysis |
| starter-redash analytics | "give me GMV / churn / revenue" | Queries Redash for metrics by project and month |
| do-it-nicely quality | "do it properly", auto on hard tasks | Forces it not to grab the first solution: gather context → 2-3 candidates with trade-offs → pick the maintainable one |
| deploy-to-our-server infra | "deploy to our server" | Deploys projects to my infrastructure (k3s) |
| add-domain-to-our-server infra | "bind a domain" | Binds a subdomain to a process (ingress-nginx + cert-manager) |
| add-project-to-starter-ai infra | "connect a client to the autopilot" | Sets up a new client project in my Telegram bot |
| + karpathy-guidelines, solid, playwright-core — for technical work. | ||
The most advanced layer. Claude runs without me on a schedule via claude -p (headless) and carries the work all the way through to posting it in a chat.
Every morning at 10:00 (GMT+7) launchd runs daily_conflicts_report.sh:
claude -p with agentsThe fine points that make this reliable:
.sent_YYYY-MM-DD) — the report goes out exactly once a day, even if the Mac was asleep at trigger time and launchd fired the task on wake.sync_recordings.py (launchd, every 3h) collects recordings from Yandex.Disk (Telemost), ~/Downloads and Pachca attachments, compresses them with ffmpeg (video → 480p, audio → 64k mono), renames them to DATE_TIME_source_context and drops them into Google Drive. Then I manually add them as sources into NotebookLM (it has no API). Smart filters cut out my own messages and non-recordings.
And for local capture I built my own open-source tool — MemorAI (a menu-bar app for macOS): it records calls and the screen itself and transcribes locally via whisper.cpp, no cloud. Also part of this "second brain."
The notion-tasks skill + /loop let Claude run in a loop: take the highest-priority task from the Todo column → move it to In Progress → do it → close it with a result → take the next one. Risky things go to Review for me to check, blocked ones go to Blocked with a reason.
The most advanced of my agents serves not me but the team. Launching a new restaurant client means dozens of design settings (palette, fonts, logos, pages, corner radii) in our CMS. A designer used to do this by hand. Now they message the bot in Telegram in plain words and drop in files, and the agent applies the changes itself. Telegram became the admin panel, Claude the executor, there's no cloud infrastructure: it all runs on the operator's laptop.
What's interesting about it — techniques that carry over to any process of the "intake → batch → apply → report back" kind:
events.jsonl, mutations go to a separate log with the exact patch, and the agent logs its "thoughts" too. A week later, when asked "why did it do that," there's an answer.Standalone techniques that recur in my work and pay off disproportionately.
Don't hit APIs during analysis. Sync into flat files first, then Claude greps locally — fast and without limits.
When you need to comb through dozens of chats/files, Claude spins up parallel agents, each reading its own slice, and the results are merged. The daily report is built on this.
In reports about people there are two levels: "what happened (quote + date)" and, separately, "what it might mean — needs checking." Don't mix them. Especially before publishing for a manager.
The first pass always overestimates, assuming greenfield. The rule: for each task, write out separately "MVP through reuse" — is there a ready-made method/field/UI block that covers 80% of the work.
Names — only from _users.json. Don't guess a name from email/handle. A partner — only if there's a chat. These rules are moved into memory to keep things factual.
write-as-me holds my style with real examples and a register tuned to the recipient. Outgoing messages sound like me, not like a "polite assistant."
A report doesn't stay in the terminal: it flies into the right Telegram/Pachca chat. By the rule "I ask you to send — send it right away, then copy me so I can catch the error."
Big analyses (partners) are saved as a dated snapshot (union.json + a README with the methodology). Next time I compare the dynamics instead of reinventing the logic.
Judgments that need to be stable go out of the agent into a human-vetted rule file (a dictionary "phrase → exact field/value"). Then the agent doesn't guess, it applies deterministically and identically everywhere.
Reduce team processes to one loop: requests drop into a queue → the agent takes them in a batch (everything accumulated at once) with full context → applies them → verifies against the source of truth → reports and logs. Keep the transport (bot/form) thin.
It's exactly this loop that gradually turns Claude from "smart but naive" into "knows my business." Most of the feedback files in memory were born exactly this way.
When the model does 95% of the work, your job shifts to one point — checking. It's not a side activity, it's the main one.
The agent isn't allowed to say "done" until it has confirmed it itself. For interfaces, run end-to-end in the browser (via Playwright): click through what it drew, take screenshots, compare against the requirements, check there are no JS errors and that the data was saved. The working pattern:
Non-obvious but important. Decisions made inside a session land in its context and are taken as fact — it won't re-check itself. So I move the quality check into a fresh session: each task gets a separate spec written to a file, and a separate agent compares the changes against that spec — without knowing how we got there — and hunts for the excess and the bad.
It generalizes beyond code too: a reviewer who sees only the spec and the result (not the author's reasoning) catches more than the same author "with fresh eyes."
"You're an experienced architect, evaluate this as an architect" within one session doesn't work: what fires isn't naming the role but structural isolation. First, in the main session, the agent gets things to a working state itself (pokes at it, checks it). And real quality control is a separate session with a clean context and only the spec on input. Separation through context, not through role prompts.
My default result format is a single .html file with a dark theme, metric cards, tables and color statuses (🔴🟡🟢). Why it works well:
The principle: the output format is chosen to match the consumption channel. HTML — for reading and forwarding; plain text — for the messenger; Markdown — for Notion.
_users.json", "partners from Telegram folders" — so it doesn't guess.Observations about the system — where there's room.
| Area | Idea |
|---|---|
| Automation | Daily conflicts is the only full-fledged auto-report. With the same pattern (claude -p + launchd + posting) you could set up a weekly summary on partners, sales or product wishes. |
| Memory | The three memory mechanisms live separately. It's worth occasionally "tidying" file-memory (deleting stale stuff) and checking that reference facts are still current — the instructions cover this, but in practice it's easy to forget. |
| insights.db | The fact-extraction pipeline into SQLite works: queries return data, the key is in the protected folder, there's a folder resolver and dedup. Room: a one-off full backfill over the whole history — on command. |
| Secrets | Tokens in a separate protected folder (chmod 600); scripts read from there with a fallback, so the automatic report doesn't fail. Room: bring the remaining integrations up to this. |
| Report template | The branded CSS and conventions (palette, components, plain-text for Pachca, "facts vs interpretations" rules) are gathered into the starter-report skill — trigger "build a report in my style." |
Happens ) Drop me a line — I'll explain it in plain terms, show you my own examples, or we can just chat about agents.
✈ message me on Telegram