Feat/web search agent

CHANGELOG.md

@@ -8,7 +8,7 @@ All notable changes to this package are recorded here. The format follows
 
 ### Added
 
-- **The agent's saved logins need no picking.** `agent()`, `AgentRun.follow_up()` and `agent_batches` take `logins`: left out, the API reads each site the workspace has a saved login for signed in with that site's login (`"auto"`), and every other site signed out, so one run can read several sites signed in; `"none"`, or a list of login ids, changes that. `login_id` is the older form of a list of one. **This needs an API with `logins`**, on the API's feature branch.
+- **The agent's saved logins need no picking.** `agent()`, `AgentRun.follow_up()` and `agent_batches` take `logins`, the saved logins the agent may sign in with: left out, every one (`"auto"`); `"none"`, or a list of login ids, changes that. The agent reads pages signed out, as the public sees them, and signs in page by page where a page needs the account, with the login for that page's site, so one run can read a site's public pages signed out and its account pages signed in. `login_id` is the older form of a list of one. **This needs an API with `logins`**, on the API's feature branch.
 - **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.

README.md

@@ -283,12 +283,12 @@ A follow-up answers after everything asked and found in the conversation before
 run = arc.agent(
     "How many employees does Stripe have, and what was Apple's revenue last year?",
     data_connections=["conn_pdl", "conn_fmp"],   # the workspace's data providers, one per provider
-    login_id=None,                               # a saved login: its site read signed in
+    logins="auto",                               # the saved logins it may sign in with (the default)
     proposals=True,                              # it may propose things to watch
 )
 ```
 
-`data_connections=` names up to two of the workspace's data-provider connections (`arc.connections`, below): People Data Labs for company data, Financial Modeling Prep for financial data. The agent may then look things up on your own key — the provider bills it, MeshArc charges no credits — and each record found is one of `run.sources`, as `{url, title, provider}`, `url` being the request it came from (your key is never in it). `login_id=` is one of the workspace's saved logins (`arc.logins`): pages on its site are read signed in, every other site signed out; logins are switched on per deployment. `proposals=True` lets the agent propose crawling a site or keeping a search or question on a schedule; nothing is made until a member approves it (`arc.proposals`).
+`data_connections=` names up to two of the workspace's data-provider connections (`arc.connections`, below): People Data Labs for company data, Financial Modeling Prep for financial data. The agent may then look things up on your own key — the provider bills it, MeshArc charges no credits — and each record found is one of `run.sources`, as `{url, title, provider}`, `url` being the request it came from (your key is never in it). The agent reads pages signed out and signs in, page by page, where a page needs the account, with the workspace's saved login for that page's site (`arc.logins`); `logins=` says which it may use (every one by default, `"none"`, or a list of ids), and `login_id=` is the older form of a list of one; logins are switched on per deployment. `proposals=True` lets the agent propose crawling a site or keeping a search or question on a schedule; nothing is made until a member approves it (`arc.proposals`).
 
 ## Monitors: a search or a question, asked again on a schedule
 

mesharc/__init__.py

@@ -1362,11 +1362,13 @@ def agent(self, prompt: str, urls: Optional[Iterable[str]] = None, schema: Optio
         secret its messages are signed with comes back once, as
         ``AgentRun.webhook_secret``.
 
-        The workspace's saved logins need no picking: each page on a site
-        with one is read signed in with that site's login, every other page
-        signed out, so one run can read several sites signed in. ``logins``
-        changes that -- ``"none"``, or a list of login ids to keep it to;
-        left out, the API's ``"auto"`` -- and ``login_id`` is the older form
+        The workspace's saved logins need no picking: the agent reads pages
+        signed out, as the public sees them, and signs in page by page
+        where a page needs the account, with the login for that page's
+        site -- so one run can read a site's public pages signed out and
+        its account pages signed in. ``logins`` says which it may use --
+        ``"none"``, or a list of login ids to keep it to; left out, the
+        API's ``"auto"``, every one -- and ``login_id`` is the older form
         of a list of one.
         ``data_connections`` names up to two of the workspace's data
         providers (one per provider): the agent may then look up company