Zeno in Claude (Desktop & Code)

The Zeno operator connects Claude Desktop or Claude Code straight to your Zeno organization. Claude acts as you — the same login, the same permissions, the same org — reading and writing across every module you can reach, with bookkeeping as home base. It’s the same engine as the in-app AI Bookkeeper, given the full API surface and a terminal to work in. Books in QuickBooks Desktop rather than Zeno? You want Zeno for QuickBooks Desktop, which connects Claude to a company file on your own machine and needs no Zeno account.

​

What you can do with it

• Categorize and reconcile — find bank-register lines by check number, payee, amount, or date; categorize them; run reconciliation.
• Enter checks, deposits, and bills — type them in, or hand Claude a PDF and let the document pipeline parse and post it (with a review gate).
• Resolve anything — “who is Ridgeline?”, “find the Operating Checking account” — Claude looks across vendors, customers, accounts, and even other modules (development projects, glass jobs, rental properties and tenants).
• Answer questions from the ledger — AP/AR aging, P&L, balance sheet, a vendor’s open bills, a customer’s payment history.
• Reach any module you can — development, glass, practice, scheduling, reports — the same as if you’d clicked into it in the app.

​

Get started

​

Staying in control

​

Inspecting campaign designs

While you are in Campaigns, every page is listed under Campaigns in the sidebar: your campaigns; Audience (contacts, lists and signup forms, segments, custom fields, import, and do-not-email); Library (templates, images and documents); and Style guide. Each page has its own URL, so you can bookmark it or open it in a separate browser tab. The Style guide is everything your AI reads before writing. Its overview shows where each part stands. Look & feel shows your name, colors, fonts and footer on a labeled sample newsletter, and you can edit them there or ask your AI to. Organization facts and Dos & don’ts hold what your AI must know and the rules each issue is checked against. The sample newsletter also appears when the campaign list is empty. Viewing it does not create a campaign; ask your AI to draft your first issue. Open Preview & Design on an existing campaign to open its own page and see its finished email alongside the blocks that make it up. Structure shows the ordered content and decorative shapes; select a block to highlight it in the preview and inspect its styling. Assets shows the logo and images used in the design, with links to their blocks. Brand shows the current colors and fonts used for the preview. Page shows the email width, canvas and footer settings. Switch between desktop and mobile previews; the page refreshes automatically after AI edits. Each content block in a column is inspectable. These design details are read-only. Ask your AI to change the campaign, using a block’s name or reference. The AI can adjust section colors, fonts, padding, borders, image sizing and focal position, button appearance, dividers, column proportions and decorative shapes. It can compose one to three columns of independent blocks, customize header logos and subtitles, style event cards, use background images with fallback colors, and adjust italic text, tracking, capitalization and decoration. A single layout block controls email width, page colors, corners, header visibility and footer styling, while preserving the mailing address and unsubscribe link. campaign_design_controls describes the supported fields; campaign_get_design reads the same inventory shown in the app. campaign_update_blocks with patch_block changes only the supplied fields and preserves the rest of the content and styling. Campaign authoring, brand changes, template and list management, and requested single-recipient test sends do not require an extra browser approval click. Bulk sending still requires explicit approval in the app. Operation receipts and organization permissions continue to apply. Content and campaign-detail changes are saved as a new revision and clear any pending send approval. Shared brand changes also clear pending send approvals. Duplicate a sent campaign before redesigning it. Templates retain the design settings for reuse. Preview and test the result before sending; email clients can differ in their support for rounded corners and image cropping.

​

Turning a flyer or document into a newsletter

A flyer, poster, PDF, Word document or slide deck is source material, not the email. Your AI rebuilds its words as real headings, text, event cards with date, time and place, and buttons for links and RSVPs, tightening the copy and applying your brand kit. Only genuine photos, logos and artwork stay as pictures, cut out of the page. A whole flyer pasted as one image is unreadable with images turned off, invisible to screen readers and hard to read on a phone, so the AI does not do it unless you ask for a small thumbnail. Drop the file under Flyers and documents on the Images page (images, PDF, Word or PowerPoint, up to 25 MB). These files stay private; only the pieces the AI crops out join the public image library. The AI reads the file with campaign_read_source (or reads a flyer already in the image library by its name), crops photos and logos with campaign_crop_source_image, and then shows you the preview and says what it rebuilt as text and what it kept as images. If a file is too blurry or is mostly artwork, the AI says what it could not read and asks for the original file or a sharper export rather than guessing dates or links. When an issue looks like a picture of a flyer (almost no text beside its images, alt text that transcribes a page, or an image named as a flyer, poster or full page), Checks asks a person to confirm it before sending.

​

Teaching your newsletter

Style guide → Overview walks you through your organization, its dos and don’ts, and what needs checking before an issue goes out. Add entries yourself, or give your AI past newsletters and guidelines to extract proposed facts and instructions. Review the proposals and finish setup before your first send. You can return to the setup page later. Organization facts holds key people and their preferred titles, locations, programs, calendar practices, audience guidance and approved wording. Facts have a source, a confirmation status and an optional expiration date. Mark information Internal context only when it should help the AI understand the organization without granting permission to publish it. Dos & don’ts groups instructions into Always do, Don’t, and Check before sending. Set each one’s importance to Required, Preference, or Human review. Exact-text checks can test whether a phrase is present or absent. Use a review for meaning, factual accuracy, image content or permission. AI-inferred instructions start as proposals; activate or remove them before completing setup. The Checks tab beside an issue’s preview shows automatic results, unresolved reviews and their evidence. Select a referenced section to highlight it in the email. Record what you verified, or why a review does not apply to that issue. Required checks block sending until resolved; preferences remain visible. Automatic text failures must be fixed in the content or playbook. Human-review checks require confirmation in the app. Unknown is never treated as passed, and text matching does not independently verify a fact or read an image. Content, audience, brand or editorial-context changes make earlier reviews out of date. The server checks readiness again when you approve a send and preserves that review with the sent issue. Expired or unconfirmed facts and possible internal information are flagged; literal matches in the newsletter require a person’s review. Your AI uses the same records through campaign_get_editorial_context, campaign_save_organization_profile and campaign_save_playbook. Read campaign_get_checks after edits and before requesting a send. AI assessments use campaign_review_check with evidence and the current issue fingerprint; they cannot satisfy human-review requirements.

​

Building site proposals

With the Sites module enabled, your AI builds and edits website proposals: a homepage concept, a sample newsletter and design notes for each prospective client, shown on the public proposal site (not indexed by search engines). Start with site_design_controls. It returns the proposal format, the homepage section types, the page markup that styling can target, and every design preset with its CSS as an example. A homepage starts with an opening section (headline, photograph and this week’s schedule) and can continue with features, events, classes, people, a full schedule, banners, text, a gallery and contact details. Ask your AI to add, reorder, restyle or remove any of them. site_update changes the proposal’s identity, design, benefits, design notes or newsletter, and site_update_sections changes one section at a time. A proposal’s overall look comes from a design preset: stored CSS chosen with design.layout. Colors, paper and font recolor any preset. Web fonts come from Google Fonts or Bunny Fonts. design.custom_css styles a single proposal. When your AI designs a look worth reusing, it saves it as a new preset with site_save_preset. Styling can rearrange and decorate the page, but cannot add new HTML elements or scripts. Edits change a draft. The AI gives you a preview link before it publishes. site_publish makes the draft live without a browser approval, and enabling a proposal lists it in the directory. A preset change appears in previews at once and on a live proposal the next time it is published. Every save is a revision. site_revisions and site_restore (or site_restore_preset) undo changes. To take a proposal down, disable it; proposals cannot be deleted. Images for proposals go in the Sites image library: site_list_images gives your AI the upload page for an image you have in chat, and site_upload_image takes a small file directly. It is separate from the Campaigns image library, so a pitch’s images never mix with your own newsletters. In the app, Sites shows every proposal with its status. A proposal’s page previews the draft homepage at desktop, tablet and phone widths, and the newsletter beside it. Click a section to see what it is made of and the reference your AI uses for it. From there you can publish the revision you are looking at, show or hide the proposal, and restore any earlier revision. Design presets lists each preset with its CSS, the proposals that use it, and its earlier versions.

​

Reviewing actions

• It’s you, bounded by you. The connection grants exactly what your own login grants over the API — your role, your org. It never elevates. If you can’t do something in the app, Claude can’t either.
• Review when the server requires it. Routine authorized work proceeds. Bulk sends, card charging or storage, access changes, unrestorable deletes, and unclassified mutations are prepared for review. The link shows the organization, effects, values and file metadata. Your approval covers that exact request for 24 hours. Return to the conversation to continue it.
• A bill can’t exist without its document. The server refuses any bill posted through the connection unless the source document rides along. The check is on the write itself, so no tool path types a bill in from memory.
• Document entry has a computed review gate. The server checks its own parse confidence against Claude’s read and blocks the commit, with reasons, when they disagree. Approval is recorded in your browser; a model-supplied human_confirmed flag cannot bypass it.
• Everything is audited under you. Writes are stamped with your user and the Claude session, so the audit trail shows exactly what was done and when.
• Verify in aggregate. Claude is told to let you confirm its work with the right report or balance, not to ask you to eyeball every row.

​

Work across modules

The connection starts with get_context: the current organization and timezone, enabled modules, effective access, roles, grants and scopes. Named reads cover rental, development, contractor, Glass, Practice, expenses, budgeting, tasks, documents, chat, scheduling, reports and administration. get_guide describes each workflow, including integration readiness and long-tail API operations. search_entities finds candidates in the app’s existing search providers; inspect_entity reads supported references without losing their organization. Search covers books, rental, development, contractor, Glass, Practice and documents. Its per-type limits mean an absent match is not proof of absence. Other queues have their own context tools and filters. get_glass_context starts with small summaries of drafts, estimates, current jobs and unscheduled backlog. Choose a queue and follow next_offset for more; choose dispatch with work_date for a date’s board. A denied queue remains unknown, queues can overlap, and source caps are explicit. Drafts are local intake records; reading them does not refresh GlassBiller. glass_part_quote marks incomplete pricing or vendor lookups as partial and identifies the failed checks. Unknown stock is not an out-of-stock answer, and a part match without working pricing is not a confirmed quote. Use read_api for JSON reads, download_file for original files and exports, and upload_file for multipart uploads (up to 20 MiB). Bill and contract document creation must use parse_document followed by commit_bill or commit_document; generic uploads refuse those endpoints. High-confidence bills with agreeing second reads proceed directly; low confidence, mismatches and duplicate overrides require browser review. Known settings reads that create records are excluded from the read-only tool. Partial failures and truncated lists are reported explicitly. Route discovery describes the global API catalog; it does not grant access to those routes. Named actions include rent escalations, development milestone completion, contractor status changes, Glass technician completion, reviewed Practice intake, expense receipt approval, recurring task completion, budget debt plans and Practice appointment booking. Appointments can send confirmation email; the server’s effect classification determines whether review is required. Other operations remain available through describe_route and call.

​

Receipts and retries

Every mutation through the Operator forwarder is recorded before dispatch. Named actions require the expected organization and a stable request ID; older tools accept these as optional fields for compatibility. Supply both on new work. An organization mismatch refuses the request before dispatch. Reuse the same request ID and exact arguments when resuming or retrying. Completed requests are not sent twice. Changed arguments with the same ID are refused. get_operation shows the durable status and any read-back verification. Some asynchronous work remains pending; generic writes may have no automatic read-back. A timeout or crash can leave an uncertain receipt, which must be checked against the actual record before another attempt. This is duplicate admission protection, not an exactly-once transaction across external systems. When a write returns success but its read-back is unavailable, the result is partial success with a warning. A read-back that disagrees with the expected record is a verification failure. Neither condition permits automatic replay. After checking the affected records, the requesting person can record an investigation on the operation page: verified completion or closure without confirmed completion, with a required note. A running claim becomes eligible after 15 minutes. Closing an investigation never cancels work or releases its request ID for reuse; late responses remain visible alongside the person’s note.

​

Skills, preferences, knowledge and history

get_context returns optional role preferences per person and organization. The AI asks about the person’s responsibilities, offers role presets or a custom description, and saves their answers with save_operator_preferences. These preferences shape questions and suggestions without changing access or the tool catalog. Onboarding introduces Skills to every user and remembers that lesson. list_skills searches short descriptions across accessible modules and returns continuation offsets. get_skill loads one set of instructions and validates its arguments. save_skill creates or updates a draft using the last-read revision. Every user can author personal Skills or propose team Skills. The owner activates a personal Skill; a module manager activates a team Skill. Personal Skills remain private, including from other managers. Team drafts are visible to their author and module managers; active team Skills reach module users. Legacy procedures keep a separate restricted audience and cannot read new personal or team rows through old API paths. People create, edit, move and activate Skills at /operator/memory. Activation refuses a version that changed after it was read and requires a browser session. Active accessible Skills also appear in MCP prompts with paginated discovery. These stored instructions are not installed native client Skill packages. get_module_knowledge and draft_module_knowledge retain manager-level access to module-wide judgment. log_work accepts a module and optional entity reference; get_work_history shows managers the module’s history and other members only their own entries. Skill command names remain unique across the organization. Omit slug when creating a Skill to derive a unique name from its title. Supply an existing slug and its updated_at only when editing or moving that Skill. Knowledge entries retain their existing explicit-slug creation behavior.

​

Getting good answers

• Say the number, not the id. “Find transaction 1183” means the check / reference number on the line — Claude searches for that. (Those fields are fully searchable; if Claude ever says it “can’t see” a field, that’s wrong — tell it to search by reference number, payee, or amount.)
• Name the entity. Full vendor/customer names and account names resolve fastest.
• Give it the document. For a bill or contract, attach the PDF rather than re-typing the figures — the pipeline dedupes and posts it with the source attached.
• Work in one conversation. Claude keeps context, so “now categorize that one to Repairs” just works.

​

How it works

The tools call the same Zeno API your browser does, in-process, carrying your token — so posting, dedup, and the audit stamp all stay server-of-record. Claude discovers endpoints with list_routes() / describe_route(), resolves names with whois(), finds register lines with find_transactions(), and enters documents through the parse_document → commit_bill pipeline. It reads a built-in field guide (zeno://guide/recipes) that maps common jobs to exact endpoints.