Scripts are the product’s emergency exit. While the built-in capabilities are enough, you do not have to think about them. But when something is missing — a source serves data in an unusual way, the needed value cannot be extracted by the usual parsing, the needed service is not among the ready channels — the corresponding step is described with your own Python code. You will not have to write the code yourself: you explain the task in words, and your agent writes, checks and runs it.
Why this is needed
The ready capabilities cover most tasks, but not all. Your own code is needed when:
- A source is built non-standardly — the data comes from a separate programmatic service, not from a page or a feed.
- The value cannot be extracted the usual way — it is substituted onto the page later, or sits in an unusual place.
- The needed service is not among the channels and publishing targets — say, a corporate messenger or your own site-management system.
- The condition cannot be expressed with the ready fields — you need your own fact, computed by your own rules.
- You want to do the processing yourself — without calling an external model.
Which step can be replaced
Your own code can be wired into nearly any point of one story’s path. The meaning is the same everywhere: the product does its work, and at the chosen step it asks your code.
- At collection — be the whole source; clean a page right after downloading; parse a letter in an unusual format; enrich an item at the entrance.
- At watching — clean a page before comparing; extract values with your own code (see Monitors).
- At processing — be the AI provider instead of an external model; add your own processing of all the material and events (see AI Processing).
- At decision-making — compute your own fact for a condition and perform your own rule action (see Rules).
- At delivery — adjust the look of a message; be the whole channel (see Delivery Channels).
- At publishing — adjust the draft text; be the publishing target (see Publishing).
How a script is built
A script is a plain text file in the Scripts section next to the other settings. It sits under version control together with them and is re-read on the fly: an edit applies from the next run; no restart is needed.
- The code can be stored in two ways — right in the settings file, or next to it as a separate file that is more convenient to edit in your own editor. One script — one of the two ways, not both at once.
- The assignment and the answer are ordinary data — the script receives what exactly to do, for which source and with which settings, and returns the result as data too. You may print anything along the way: the last answer is the one that counts.
- Secrets are stored together with the script — tokens and passwords are named in it and masked when the settings are read, as everywhere in the product.
- Your own permanent place for data — every script has its own folder: convenient for remembering where the collector stopped reading and continuing from the same spot.
- Shared libraries install themselves — when a script needs extra libraries, they are listed once, and the product installs them itself.
Testing and the run journal
A script can fail like any setting, so it is always see-through.
- A test run — from the “Scripts” screen you can ask the agent to execute the script now and show what it returned, without waiting for the schedule.
- The run journal — every script has its own history: at which step it was called, what the trigger was, what the subject was, how it ended, how long it took and what it answered (or where it stumbled). Both the successful runs and the error with its reason are visible.
- Wiring is visible — next to a script, the settings that reference it are shown. It is immediately clear what breaks if it is deleted — so the product will not let you delete a script while something references it. An unwired script is marked separately.
- Your own entries on the “Scripts” screen — what the script does, which step it is wired to and how the recent runs went: Observation Screens.
Limiters
Your own code is the freest part of the product, so it comes with a clear harness. Everything is configurable; the values below are the defaults.
- The master switch — one motion stops all the scripts at once. Every skipped run is honestly recorded in the journal with a reason.
- A time allowance per run — one minute, up to ten when needed. A hung script is killed together with all the processes it started.
- No more than two runs at once — the scripts do not eat the whole server while the news is being collected and processed.
- A data volume limit — up to one megabyte in each direction. Extras belong in the script’s own folder, not in the answer.
- The run journal is kept for 30 days — and is cleaned together with the rest of the archive by retention.
- A breakage is visible at once — when the server has no Python or the libraries are still installing, the “Scripts” screen shows a warning with a hint about what to check, not silence.
Honest limits
- Scripts run unsandboxed. This is the owner’s trusted code: it gets the same access to files and the network as the product itself. The limits here are not technical but disciplinary — which is why scripts should be written and checked together with the agent.
- The management key is never given to a script. It cannot change the product’s settings for you.
- A script extends a step but does not change the product. When you need different logic of the product itself, that is a question of the source-code license, not of scripts.
The rules and prices — the News Agent Licensing section.
Next → Documentation index