v2.7.16: Your Employee Can Rewrite Its Own Call Script, and Your Crons Stop Firing Once a Day

Every release has a theme, even when nobody plans one. This week's theme is control moving one step closer to the person who actually needs it. Your employee can now edit the instructions it follows on phone calls. Your recurring schedules stop being throttled to once a day if you are paying for your own compute. And your webhook skill finally hands back a URL you can paste somewhere instead of a fragment you have to guess the front of.

Four changes shipped in v2.7.16. Here is what each one actually does for you.

Your employee can now manage its own call prompt

If your AI employee has a phone number, it has a set of custom call instructions behind it. That field, the one labelled "Custom instructions" in the telephony settings, gets appended to the prompt the employee runs during a live voice call. It is where you put things like "always confirm the caller's name before booking anything" or "if someone asks about pricing, quote the tiers and offer a callback, never improvise a discount."

Until now, changing it meant going to the settings panel yourself. That is fine once. It is annoying the fourth time you finish a call, notice the agent handled an objection badly, and want to patch the behaviour before the next one comes in.

The new call-prompt skill closes that loop. You can now say "your last call went off the rails when they asked about refunds, add a rule about it" and your employee will read its current call prompt, propose an updated version, and apply it once you say yes.

That last part is not optional. The skill is built with a hard rule: the employee must show you the full proposed prompt and get your explicit approval before writing anything. No silent edits to the script that represents you on live calls. If you have ever watched an agent confidently "improve" something you did not want improved, you already know why that guardrail exists.

The rest of the fine print:

• Available to every employee, on EE and SaaS plans only. Not on Community Edition, not on the free tier.
• If the employee has no phone number assigned, the skill refuses with a clear explanation rather than failing in some cryptic way.
• Prompts are capped at 4000 characters, which is far more room than a good call prompt needs.

Under the hood this is a pair of authenticated internal endpoints, GET and PUT on /api/telephony/internal/call-prompt, scoped to the employee's own token. An employee can read and write its own call instructions and nothing else.

The skill install bug that made new skills invisible

While building the above, we found something worse than the feature itself.

When you installed a skill through the UI, it landed on disk correctly, the CLI worked, everything looked fine. But the skill was never documented in the employee's CLAUDE.md file, because its description was missing from the internal getSkillDescription map. The agent had a fully functional tool sitting in its workspace and no idea it existed.

That is the quiet kind of bug. Nothing errors. Nothing logs. The employee just says "I do not have a way to do that" and you assume the feature was never built. The description has been added, and a targeted resync pushed the fix to existing instances.

If you have installed a skill recently and your employee acted like it had never heard of it, this was why.

Recurring tasks are no longer capped at once a day

This one is a straight unlock.

The scheduler had a guard preventing any recurring task from firing more than once per calendar day in UTC. It was written for the free tier, where unbounded cron loops are a real cost problem. It was applied to everyone, which was not the intent.

Fixed. The once-a-day ceiling is now gated on the free tier flag only. On BYOK, SaaS, and Enterprise Edition, your crons behave like crons:

• 0 9,18 * * * for a morning and evening pass
• */10 * * * * for a genuine monitoring loop
• Anything else you want, at whatever cadence your workload actually needs

Free tier keeps the once-a-day limit, which is the right trade for a plan that costs nothing.

If you built a schedule in the last few weeks and quietly noticed it only ever ran the first time each day, it was not your cron expression. Go re-check the ones you gave up on.

Editing your profile stopped throwing a 500

A PUT to /api/auth/profile was returning a 500 with "gender is not defined." When gender was removed from the registration and onboarding flow, a stray reference stayed behind in the profile update query. Any attempt to save profile changes hit it and died.

The line is gone, the endpoint tests clean at 200, and profile editing works again. Small fix, but it was blocking something completely ordinary.

Webhooks return a URL you can actually use

The webhook-manager skill had a similar shape of problem: technically correct output, practically useless.

When an employee created a webhook, the skill returned a relative path, something like /api/webhooks/incoming/<token>. The employee had no way to reconstruct the base URL because PUBLIC_INSTANCE_URL was never injected into employee containers. So agents would create a perfectly valid webhook and then tell the user they could not provide a link because they did not know the public address of their own instance.

Three parts to the fix:

1. The container manager now injects PUBLIC_INSTANCE_URL at spawn time, resolved through the same priority chain the rest of the system uses: dkim_domain from the database, then CNAME, then DOMAIN, then BACKEND_URL, normalised to https://.
2. The CLI now emits an explicit warning if the URL still comes out relative, so a misconfiguration announces itself instead of silently degrading.
3. The skill documentation leads with a note that the commands return the complete URL, so the agent stops second-guessing its own output.

Verified end to end: creating a webhook now returns the full https://your-instance/api/webhooks/incoming/<token>, ready to paste into whatever service is going to call it.

One caveat worth knowing: existing employee containers only pick up the new variable on their next spawn. If your employee is still returning a relative path, restart it once and it will sort itself out.

The pattern here

Three of these four changes are the same story told differently. A feature worked, but the agent could not see it, could not describe it, or was artificially prevented from using it fully. Capability is not the same thing as usable capability, and the gap between them is where most of the frustration with AI agents actually lives.

Ship the tool, then make sure the agent knows it has it. That is most of the job.

Running Geta.Team already? Update and go re-enable the crons you gave up on. Not running it yet? Start free with one employee and 100 credits a day, no card required.