DEV Community: Dmitry Lukashov

Four offline checks before giving a marketing agent API access

Dmitry Lukashov — Fri, 16 Oct 2026 17:51:10 +0000

A marketing agent can produce valid JSON and still make the wrong decision. It can average ratios instead of totals, compare packages with different scope, interpret an incomplete CRM response as absence, or turn a local email check into permission to send.

Here are four small offline exercises I use to make those errors visible before connecting an agent to a live account. Each has synthetic input and a result you can reproduce with Python 3.9+ and the standard library. There is no paid-core dependency or signup.

These are four independent tools, not an integrated marketing pipeline or a benchmark of any particular model. I maintain the modules as part of Lookatshow. AI assistance was used to prepare this article; the commands below were run against the public artifacts on 16 October 2026.

1. Check the denominator before recommending an ad change

Direct report audit reads a normalized placement CSV or TSV. It does not connect to Yandex Direct.

Download and unpack the v0.1.0 ZIP, open its directory, then run:

python3 -B direct_report_audit.py --json audit examples/synthetic-placements.csv --max-cpa 1000

The fictional input contains five rows and four grouped placements. The result has 97 clicks, 6,000 RUB cost and 5 conversions. Total CPA is 1,200.00 RUB, calculated from total cost divided by total conversions. Two placements are manual-review candidates under these demonstration thresholds.

Give the agent a narrower task than "optimize this campaign":

Recalculate the totals from the fixture. Explain why total CPA is a ratio of sums. List the review candidates and their reasons. Explain which attribution, tracking and sample-size checks would be needed before a campaign change.

An attractive recommendation to exclude a placement is not a passing answer. The program has not established causal waste or a complete customer journey. Native export headers and cost units must also be normalized first; the CLI is not a universal parser for every advertising export.

2. Separate a price change from a package change

Competitor offer radar compares supplied local snapshots. It does not scrape websites or verify that an offer was really available.

Use the pinned source archive. This later source revision includes a console-encoding fix; the original v0.1.0 release ZIP predates it.

python3 -B competitor_offer_radar.py compare examples/before.json examples/after.json

In the synthetic strategy-session package, the price changes from 10,000 to 12,500 RUB: +25%. Delivery changes from four to six business days, and interview quantity changes from two to one. The output includes scope_changed_warning=true.

Ask the agent:

Show the arithmetic and identify the changed scope. Can this establish a 25% price increase for equivalent work? What does an offer absent from the later snapshot actually prove?

A useful answer preserves the warning. Missing from a supplied snapshot does not establish that a competitor discontinued the product. Different package content does not support a clean like-for-like price conclusion.

3. Keep incomplete CRM reads out of the absence queue

Bitrix read kit has a synthetic demonstration that needs no portal or credentials. Its separate live mode is read-only and limited to what the configured user can see.

Download the v0.1.0 ZIP, unpack it and run:

python3 -B bitrix_read_kit.py demo

There are five fictional open deals and three unique visible unfinished activities. One deal has a scheduled activity, one an overdue activity, one an undated activity, one a complete activity read with no visible unfinished item, and one an incomplete activity read.

Ask:

Which deal supports an absence claim, and which needs a coverage check? Keep overdue-but-present activities separate from missing ones. State the demo's analysis time.

Deal 101 has the complete empty read. Deal 105 has incomplete coverage: its absence status cannot be established. The fixed analysis time is 10 October 2026, 10:00 MSK. Rerunning the fixture today is not a fresh portal capture, and a CRM activity is not proof of an agreed customer next step.

4. Keep a local eligibility check separate from sending

UniSender campaign kit checks a draft, a supplied permission ledger and a suppression file locally. It has no UniSender API connection, contact import or send command.

Download the v0.1.0 ZIP, unpack it and run:

python3 -B lookatshow_mail_plan.py demo

The six invented rows produce one eligible-under-supplied-rules row and five excluded rows. The reasons are a duplicate address, suppression, expired supplied permission, an unsubscribe flag and no affirmative supplied permission. All addresses use example.invalid.

The JSON still reports:

{
  "consent_evidence_verified": false,
  "legal_permission_verified": false,
  "provider_acceptance_verified": false,
  "deliverability_verified": false,
  "sending_performed": false
}

Ask the agent to explain those false fields before proposing any next step. A successful command means the local calculation completed. It does not verify a person's actual consent, a provider's acceptance or delivery. The demonstration also uses a fixed evaluation time rather than today's date.

A compact acceptance prompt

After downloading and reading the four modules' READMEs, try this with your coding agent:

Run only the four bundled synthetic commands above. For each exercise, report the exact command, exit code, observed values, supported conclusion and one tempting unsupported conclusion. Compare observed values with the stated expectations and report mismatches. Do not connect accounts, fetch customer data, send messages, alter campaigns or upload files. Stop and explain any missing input. Do not present synthetic results as a client case.

The distinction to inspect is between a calculation, the evidence it actually received, and the action someone wants to take. Passing these examples does not establish readiness for a live account. Failing one gives you a specific behavior to fix first.

The open-tools catalog links the installation instructions, licenses and limitations. Each module is independently usable for free. There is no hidden telemetry in these offline exercises. If you pass real output to a cloud agent later, that provider's data policy still applies.

If you try a fixture, which unsupported conclusion did your agent make? A command, environment and synthetic mismatch are useful in a comment or repository issue; please keep customer exports, addresses and credentials private.

Prepared by Dmitry Lukashov. If your team needs help adapting this kind of evidence check to its own workflow, discuss implementation. Scope and cost are agreed separately from the free tools.

An empty CRM response is not evidence of no follow-up

Dmitry Lukashov — Thu, 15 Oct 2026 08:40:00 +0000

Suppose your CRM agent returns this sentence:

Two deals have no follow-up. Ask their owners to fix them.

The JSON behind it contains two empty arrays. One belongs to a completed activity read. The other belongs to an incomplete read. The agent has turned a collection limit into an accusation.

You don't fix that with a more persuasive prompt. Keep the evidence needed to support the statement, and test the rule before asking a model to explain it.

Here's a small, reproducible example using Bitrix read kit, a free MIT-licensed Python CLI from my Lookatshow project. Every record below is synthetic. You need no CRM account, credentials or paid core.

Reproduce the mistake without connecting a CRM

Use Python 3.9 or later. The package uses the standard library:

git clone https://github.com/ilookatshow-gif/bitrix-read-kit.git
cd bitrix-read-kit
git checkout --detach e102c33d20ed5d74591092433e78fb9019e1cc0d
python3 -B bitrix_read_kit.py demo

Use python instead of python3 if that's your interpreter name. Pinning the commit makes the example repeatable even if the default branch changes.

The fixture contains five fictional deals and three unique unfinished activities. Look at these two rows in the output; this is an excerpt, not the full report:

[
  {
    "deal_id": 101,
    "activity_read_complete": true,
    "visible_open_activity_ids": [],
    "flags": ["no_visible_open_activity"]
  },
  {
    "deal_id": 105,
    "activity_read_complete": false,
    "visible_open_activity_ids": [],
    "flags": ["activity_coverage_incomplete"]
  }
]

The arrays match. The conclusions don't.

This tempting filter produces the wrong work queue:

missing = [
    row["deal_id"] for row in report["deals"]
    if not row["visible_open_activity_ids"]
]
# [101, 105]

A narrower predicate preserves what the reader actually established:

missing = [
    row["deal_id"] for row in report["deals"]
    if row["activity_read_complete"]
    and not row["visible_open_activity_ids"]
]
unknown = [
    row["deal_id"] for row in report["deals"]
    if not row["activity_read_complete"]
]
# missing: [101]; unknown: [105]

Even missing needs a careful label: no visible unfinished CRM activity, not “no customer agreement.” A promise could live in a conversation or another system. The useful next action is to check the deal card and correspondence, not reprimand an employee.

Make coverage part of the data contract

Bitrix24 documents that crm.activity.list respects the current user's permissions, paginates results, and returns next when another page exists. A successful HTTP response doesn't establish that your integration collected the whole selection, much less every record in the company.

This module keeps coverage per deal. It also reports the collection window and refuses to claim an atomic portal snapshot:

{
  "scope": "records_visible_to_webhook_user",
  "selected_deal_pages_complete": true,
  "all_selected_activity_pages_complete": false,
  "snapshot_is_atomic": false,
  "portal_wide_completeness_proven": false
}

That object is the fixture's actual coverage output. true for deal pages and false for activity pages aren't contradictory: the selection of deals finished, but one deal's activity read didn't.

Don't discard an entire partial report either. An incomplete read that contains an overdue activity still proves that particular activity was visible. It doesn't prove there were no others. In a separate regression, adding synthetic unfinished activity 205 to deal 105 produces both activity_coverage_incomplete and overdue.

Positive evidence survives incomplete coverage. An absence claim doesn't.

A later clock is not a newer snapshot

Run the same saved input at two analysis times:

python3 -B bitrix_read_kit.py audit \
  --input examples/synthetic-snapshot.json \
  --as-of 2026-10-10T10:00:00+03:00

python3 -B bitrix_read_kit.py audit \
  --input examples/synthetic-snapshot.json \
  --as-of 2026-10-13T10:00:00+03:00

Field	First analysis	Later analysis
Unique visible unfinished activities	3	3
Deals with a scheduled activity	1	0
Deals with an overdue activity	1	2
Deals with incomplete activity reads	1	1

Activity 201 on deal 102 has a deadline of 10 October at 12:00 MSK. The first analysis happens before it; the second happens after it. Nothing entered or left the input file.

Both reports retain captured_at: 2026-10-10T06:00:00Z. The later report doesn't tell you whether someone completed the activity after capture. It answers “how does this saved evidence classify at this time?”, not “what is happening in the portal now?”

Keep that difference in the UI. Show capture time beside analysis time. Before a consequential action, obtain an authorized fresh read rather than merely changing --as-of.

There is another date trap: Bitrix24's official activity example uses 9999-12-31 for an activity with no deadline. The kit classifies the fixture's activity 203 as undated. It doesn't celebrate an appointment scheduled thousands of years ahead.

Give the model a bounded job

Once the checks run, use the model to explain evidence, not manufacture certainty. This prompt works with the included fixture:

Run the two offline audits at the exact times in this article. Don't connect a portal or change the CRM. For each deal, give its ID, visible unfinished activity IDs, coverage, supported conclusion and manual verification step. Keep incomplete reads separate from complete empty selections. Explain why activity 201 changes classification without changing the unfinished count. Distinguish capture time from analysis time. Don't infer lost sales, employee failure or an agreed customer next step.

Make the same boundary executable in your integration tests:

for row in report["deals"]:
    flags = set(row["flags"])
    assert not {
        "no_visible_open_activity",
        "activity_coverage_incomplete",
    } <= flags

That assertion catches one specific contradiction. It doesn't certify the underlying portal data. Keep provider errors, malformed records and permission checks out of the “empty success” path too.

For this article, autonomous AI agents reran the pinned source's 95 tests and its clean-install smoke test on macOS arm64 with Python 3.9.6. They passed. No real customer portal supplied these results. Real capture files still contain linkable internal CRM IDs even without names or phone numbers; don't publish them or hand them to an unrelated AI service.

Use the free module, then decide what needs integration

Start with the pinned source and fixture. You can keep the offline checks independent of any agent host. The CLI isn't an MCP server; adding a model doesn't change its evidence limits.

I'm Dmitry Lukashov, creator of Lookatshow, a marketing-management system for AI agents. If your team needs a CRM review workflow with explicit permissions, freshness rules and a separate read-before-write check, discuss that implementation with me. The module remains free and doesn't require that service. I share practical notes at @lookatsoul.

Disclosure: this is my project. Autonomous AI agents prepared the article and checked its code and outputs. The linked source, fixture and commands make the technical claims independently testable.