Follow-ups, tables, monitors in full, triggers, proposals, sub-accoun…

CHANGELOG.md

@@ -8,6 +8,16 @@ All notable changes to this package are recorded here. The format follows
 
 ### Added
 
+- **Follow-ups and conversations.** `AgentRun.follow_up(prompt, ...)` asks the next question in a run's conversation -- it takes what `agent()` takes, answers after everything asked and found before it, and may read again, free, any page the conversation read -- and returns its `AgentRun`. `conversations(q=None, limit=25)` walks the workspace's conversations, the latest message first; `conversation(id)` reads one with every run in it. A message that is not the conversation's latest is a 409 `conflict`. **These need an API with follow-ups**, on the API's feature branch, not yet on mesharc.dev.
+- **`agent()` takes `login_id=`, `data_connections=` and `proposals=`**: a saved login its site is read with; up to two of the workspace's data-provider connections (People Data Labs, Financial Modeling Prep), which the agent looks company and financial data up with on your own key, at no MeshArc credits, each record one of its `sources` as `{url, title, provider}`; and leave to propose things to watch, for a member to approve. Each is sent only when given. `trace()` knows the `lookup` step. **These need an API with saved logins, data providers and proposals**, on the API's feature branch.
+- **`arc.agent_batches`: the agent over every row of a table.** `preview`, `start`, `get`, `rows`, `wait`, `list`, `cancel` and `export` -- one agent run a row, its prompt and starting URLs filled from the row's columns as `{{column}}`, its answer the row's new columns; `max_credits_per_row` caps each row and the batch never spends more than rows x that cap. **This needs an API with `/agent/batch`**, on the API's feature branch.
+- **Monitors in full.** `monitors.create` and `update` take `budget` (per run and per month, in credits), `alerts` (email and a chat webhook), `add_to_project`, `rows` (follow a list answer record by record), `destination` and `sentiment` (a news monitor's tone, scored by your LLM connection); `{}`, `""` and `False` are sent and clear a setting, only `None` is left out. New: `monitors.overview()`, `rows()`, `rows_page()`, `row()`, `row_events()` and `export_rows()`.
+- **`arc.triggers`** (`create`, `list`, `get`, `update`, `delete`, `fires`, `preview`): a project's change or a monitor's run starts an agent run, a re-crawl, a monitor run or a re-check. **`arc.proposals`** (`list`, `approve`, `dismiss`): what agents proposed to watch. **`estimate(kind, schedule, ...)`**: about what a crawl, search or agent on a schedule costs a month, before it is saved.
+- **Sub-accounts.** `arc.sub_accounts` (`list`, `create`, `get`, `update`, `keys`, `create_key`, `revoke_key`) makes and manages workspaces for your customers on a Scale or Enterprise plan. `arc.as_sub_account(id)`, or `MeshArc(key, tenant=id)`, is a client whose every request carries `X-MeshArc-Tenant` and acts on that sub-account. `TENANT_HEADER` names the header.
+- **`arc.connections`** (`providers`, `list`, `create`, `get`, `update`, `delete`, `test`) and **`arc.logins`** (`list`, `update`, `test`, `delete`): the workspace's connections -- a data provider among them -- and its saved logins. Admin keys only.
+- **Four MCP tools: `create_monitor`, `list_monitors`, `pause_monitor` and `get_monitor_rows`**, twenty-one in all. `create_monitor` keeps a web search (news too) or an agent question on a schedule, an agent one held to its starting sites as `run_agent` is, with an optional monthly cap and record-by-record following, and sends its own idempotency key from its inputs and the ten-minute window. `list_monitors` lists them, or reads one with its latest runs; `pause_monitor` pauses and resumes one; `get_monitor_rows` reads an agent monitor's records and what moved, within 60,000 characters. `list_monitors` and `get_monitor_rows` only read and work on a read-only connection; the other two need write access. **These need an API with monitors**, on the API's feature branch.
+- **The MCP `create_project` tool takes `max_credits_per_run` and `max_credits_per_month`**: a run stops at its cap, keeping what it read, and scheduled runs are skipped once the month has spent its cap. On a kept crawl (`crawl_id`) they are set on the project it becomes.
+
 - **`cancel_agent(run_id)` stops an agent run by its id**, with no handle needed: what `AgentRun.cancel()` does, in one request. `cancel_job(kind="agent")` in MCP uses it, so it no longer reads the run first.
 - **The MCP `run_agent` tool keeps an agent given starting `urls` on their sites** unless `allowed_domains` says otherwise -- each URL's host, lower case, without `www`, the API keeping its subdomains -- as the app does, since a page the agent reads could tell it to go elsewhere. `allowed_domains=[]` lets it read any site; with no `urls` there is no limit. The client's `agent()` is unchanged: it sends what it is given.