Skip to main content
Real questions from Dataleap trainings and customer conversations, answered briefly. Each answer links to the page that goes deeper.

​
Building and improving

Two things to try. If the workflow is data-heavy and deterministic, ask the agent “Do you use PTC?” — batching the tool calls in a script often fixes both speed and cost. Otherwise, raise its preset one tier and test again — complex workflows sometimes need a bigger context window. The reverse also holds: if it runs well but feels expensive, try a tier lower and check the results stay good.
Judge it on real work, not on a benchmark. Run it against examples where you already know the right answer, and read the result in Runs — every execution with its status, output, duration, and cost.When you change something, versioning keeps the working state one restore away: run the new version on the same examples, compare, and keep whichever wins. If the output drifts, tighten its instructions before you reach for a bigger model.
Start with the run, not with the work. Open Runs on the agent — each execution shows its status, output, duration, and cost, so you see what came back before you check anything else. A Degraded or Failed run also tells you in one line what fell short.If the result is mostly numbers, ask for a dashboard and scan one page instead of a wall of text. To confirm what the agent actually touched in your systems, admins have every tool call in Integration Activity.
No. Describe the problem — Dataleap architects the system for you, including sub-agents and PTC where they help. Your job is a clear goal, not a system diagram. The one nudge worth knowing: if a deterministic, data-heavy agent feels slow or expensive, ask it “Do you use PTC?” — it will rethink its structure.
Two ways. Ad hoc: open the relevant page in your data tool (e.g., Snowflake), copy the URL into the chat, and add a short description of how the data is structured. Durable: create an org-wide skill that defines your metrics once — what each one means and what it’s called in the data — and every agent anyone builds uses the same definitions.
Uploads are capped at 50 MB — the same limit for a chat attachment and a Knowledge document. For anything bigger, don’t upload at all — just link the file: connect the app where it already lives (SharePoint, Google Drive, OneDrive, …) and let the agent access it there. That handles files of any size. For reference documents an agent should use permanently, see Add knowledge.
Knowledge is context for one agent: the documents and facts it should work from. A skill is a procedure or standard — your pricing method, your report format — that many agents follow, and that you update in one place.Rule of thumb: a document is knowledge, a rule that should hold everywhere is a skill.
Yes — OCR is a built-in tool, along with web search, transcription of voice memos, image generation, and webhooks. No setup needed.
No. A copy carries the original’s triggers, but they arrive disabled. Reconfigure them for the copy’s job before you switch them on — otherwise the copy fires alongside the original.

​
Spend and control

Your costs split into chat costs (building — high at first, zero once the agent is done) and run costs (every execution). For run costs, the levers in order of impact: use event triggers instead of schedules, ask your agent “Would PTC make sense here?” for data-heavy deterministic work, dial the model tier down once the agent is proven, and pre-filter data at the source. Full picture: Credits & usage.
Yes, and the caps that actually stop a run are the weekly ones. Admins set a weekly member budget per person — resolved user → team → org default, most specific wins — and a weekly team-agent budget shared by every agent on a team. Both are hard caps, which is also your answer to a run that goes off the rails.The monthly organization figures on the same page are for monitoring: passing one doesn’t block anything. Credits & usage has both, plus the levers that make agents need fewer credits in the first place.

​
Sharing and ownership

Three ways, depending on how much they should be able to change:When to share what is the full decision table.
Whoever holds the space it lives in. An agent in your personal space stays yours; Copy to team gives the team its own copy while your original stays unchanged.A locked template stays with its owner — clones follow the owner’s updates, but each clone runs on its user’s own connections and credentials. Admins can see the owner of every agent in the per-agent list under Analytics.
Every skill has a reach: personal, team, or org-wide. A team space has its own Skills tab, so a business unit maintains its own standards without touching anyone else’s, and publishes org-wide only what genuinely applies to everyone.Distribution is the same mechanism: change the skill once, and every agent that uses it follows from the next run.
Share early and visibly: proven agents go into the team space or become templates teammates can clone, and shared standards become skills. Many teams pair this with a short weekly or biweekly champions sync — who’s building what, with clear ownership per workflow.
Agents in your personal space depend on you and your credentials. For workflows others rely on, move them to a team space: they run on team-level credentials (ideally service accounts), everyone can see runs and history, and access survives when people leave — handover is built in.
Through its link. There is no library of dashboards to browse, so keep the link — or the chat it came from. If other people need it, share the page instead of sending the file around.

​
Data and governance

Put the guardrails on the tools, not on the people. Admins allow or block each tool of each integration — they are grouped into read-only and write, so it is visible which ones can act in your systems. Whole integrations can be moved to Restricted, usable only on request, and those requests are approved or rejected in one click.Two layers underneath: the org-wide system prompt applies rules like PII handling to every agent automatically, and team agents run on team connections — use service accounts there, never personal logins. Every tool call in the organization lands in Integration Activity.
There is no on/off switch for either, and neither reaches your systems on its own: a skill is written instructions, and a dashboard is a page built from data the agent could already read.What you do govern is the access underneath — which tools agents can use, who a skill is shared with, and who can open a dashboard.
You see every execution of your own agent in Runs, including the conversations of people you gave Use only access. In a team space, the whole team sees the runs and history of team agents — that is what makes handover work.Admins see it organization-wide: every tool call in Integration Activity, and cost and run counts per agent in Analytics.

Your first agent

Ready to build? Start here.

Credits & usage

All the cost levers in one place.