Comment 1 — Follow-up: on_demand still rejected (after Seren update)
When to post: After you heard Seren was updated to support on_demand.
We tried deploying again with mode: "on_demand" after the update. The deploy API still returns:
Request: POST https://api.serendb.com/publishers/seren-cloud/deploy with "mode": "on_demand"
Response: 400 Bad Request — "Invalid mode 'on_demand'. Must be 'always_on' or 'cron'."
So from our side it still looks like only always_on and cron are accepted. Can you confirm whether:
The new mode is live on api.serendb.com (or if we should use a different endpoint)?
The exact mode value the API expects (e.g. on_demand vs on-demand vs something else)?
Once that’s clear we can redeploy as on_demand and use POST .../run for one-shot invokes. Until then we’re blocked on always_on (no invoke URL, run returns 500).
Comment 2 — Short base URL for others hitting this
When to post: Optional; helpful for anyone else trying the APIs.
For anyone calling the control-plane today, the short base URL works:
Base: https://api.serendb.com/publishers/seren-cloud
GET agent: GET .../agents/{id}
POST run: POST .../agents/{id}/run (with JSON body; returns 500 for always_on agents)
Deploy: POST .../deploy
So the issue isn’t the base path — it’s that for always_on we have no way to actually invoke the skill (no invoke URL in the response, and run tries to create a Job and fails).
Comment 3 — What would resolve this for us
When to post: Optional; summarizes what would unblock you.
What would resolve this for us (in order of preference):
Invoke URL in deploy/agent response — Deploy and/or GET .../agents/{id} return a field (e.g. endpoint, invoke_url, or url) with the base URL to POST { "state", "input" } to for always_on agents.
Run proxies to always_on — POST .../agents/{id}/run with a body is proxied to the running container and returns the skill response (e.g. { state, prompt, outputs? }) instead of creating a K8s Job.
Supported on_demand mode — If the API accepts an on_demand (or equivalent) mode, we can deploy that way and use run for one-shot invokes; we’d just need confirmation that it’s live and the exact mode string.
Any one of these would unblock us. Thanks for looking into it.
Comment 4 — One-line “still seeing 400” follow-up
When to post: Quick follow-up if someone says on_demand is deployed.
Tried again just now: POST .../deploy with "mode": "on_demand" still returns 400 — "Invalid mode 'on_demand'. Must be 'always_on' or 'cron'." So we’re still unable to deploy as on_demand from here.
QUESTION:
ARE AGENT SKILLS REQUIRED TO BE DEPLOYED AS PUBLISHERS?
Comment 1 — Follow-up: on_demand still rejected (after Seren update)
When to post: After you heard Seren was updated to support on_demand.
We tried deploying again with mode: "on_demand" after the update. The deploy API still returns:
Request: POST https://api.serendb.com/publishers/seren-cloud/deploy with "mode": "on_demand"
Response: 400 Bad Request — "Invalid mode 'on_demand'. Must be 'always_on' or 'cron'."
So from our side it still looks like only always_on and cron are accepted. Can you confirm whether:
The new mode is live on api.serendb.com (or if we should use a different endpoint)?
The exact mode value the API expects (e.g. on_demand vs on-demand vs something else)?
Once that’s clear we can redeploy as on_demand and use POST .../run for one-shot invokes. Until then we’re blocked on always_on (no invoke URL, run returns 500).
Comment 2 — Short base URL for others hitting this
When to post: Optional; helpful for anyone else trying the APIs.
For anyone calling the control-plane today, the short base URL works:
Base: https://api.serendb.com/publishers/seren-cloud
GET agent: GET .../agents/{id}
POST run: POST .../agents/{id}/run (with JSON body; returns 500 for always_on agents)
Deploy: POST .../deploy
So the issue isn’t the base path — it’s that for always_on we have no way to actually invoke the skill (no invoke URL in the response, and run tries to create a Job and fails).
Comment 3 — What would resolve this for us
When to post: Optional; summarizes what would unblock you.
What would resolve this for us (in order of preference):
Invoke URL in deploy/agent response — Deploy and/or GET .../agents/{id} return a field (e.g. endpoint, invoke_url, or url) with the base URL to POST { "state", "input" } to for always_on agents.
Run proxies to always_on — POST .../agents/{id}/run with a body is proxied to the running container and returns the skill response (e.g. { state, prompt, outputs? }) instead of creating a K8s Job.
Supported on_demand mode — If the API accepts an on_demand (or equivalent) mode, we can deploy that way and use run for one-shot invokes; we’d just need confirmation that it’s live and the exact mode string.
Any one of these would unblock us. Thanks for looking into it.
Comment 4 — One-line “still seeing 400” follow-up
When to post: Quick follow-up if someone says on_demand is deployed.
Tried again just now: POST .../deploy with "mode": "on_demand" still returns 400 — "Invalid mode 'on_demand'. Must be 'always_on' or 'cron'." So we’re still unable to deploy as on_demand from here.
QUESTION:
ARE AGENT SKILLS REQUIRED TO BE DEPLOYED AS PUBLISHERS?