Toolkits and actions
A CodeKit toolkit is a container you create from the Tools page with Create Tool. It appears on the Connected tab beside the toolkits you connected from the Directory, with a wrench icon until you upload a logo. Configure opens its page. A new toolkit holds one Greeting action as a starting point. A custom action is one function inside that toolkit. Each action has a display name, a description, an input schema, and a fixed output shape ofsuccessful, data, and error. The model reads the name and the descriptions to decide when to call the action and what to send, so they matter as much as the code.
You write only the function body. Tars builds the code and hosts the result, so there is nothing to run or maintain. Each action opens in its own editor page with a Configure rail beside the code.
Secrets
API keys and tokens never sit inside action code. You store them as secrets, and the running action reads them asenv.KEY. Values are encrypted at rest, and secret values are redacted from execution logs. Keeping action inputs and outputs out of execution logs is a separate opt-in, the Enable redaction switch on the Log privacy card.
A secret has one of two scopes. A Toolkit secret is shared with every action in the toolkit and is listed under Environment Variables on the toolkit page. An Action secret belongs to one action only.
In the editor, each secret chip carries a T or A badge. The legend under the Secrets card reads Toolkit-wide and Action-only.
Because the code and the secret are separate, rotating a key means updating the secret’s value. A deployed action reads the new value without a new deployment. A newly added key is readable only after the next deployment.
Calling connected toolkits from an action
A custom action can call the toolkits your organization has already connected, such as Gmail or Slack. In the editor, the Connected Toolkits card opens the Connect Toolkits dialog, where you select toolkits and pick the actions to expose in your code.toolkits.{slug}. Credentials stay with the connection, so the custom action never handles them. Each connected toolkit chip shows a live connection dot, and the connection itself is managed as described in Connect a toolkit.
Deployment
Saving stores your edits. Deploying builds the code and releases the action to your whole organization. The badge in the editor header moves from Draft through Building and Deploying to Deployed, or ends in Error. The Deploy button stays disabled while the code has errors, and its tooltip names the blocker. Once the badge reads Deployed, agents that use the action run the new version on their next call. While a deployment runs, or after it fails, calls to the action fail. An action can be switched on only after it is deployed. A copy made with Duplicate action or Duplicate toolkit starts switched off and not deployed.How agents use custom actions
A deployed action is a tool. The Tools tab of the gambit palette lists CodeKit under Connected. A builder drags it into a flow as a tool gambit, then picks the toolkit inside the gambit editor. The tool gambit runs in one of two modes:- In agent mode, it offers the actions you include to an AI Agent gambit. Tool gambits connected to an AI Agent gambit show as badges in its Tools & Capabilities region.
- In Workflow Mode, it runs one action as a flow step, with explicit inputs and On Success and On Failure routes. Only an enabled, deployed action can be selected.