CoachDiscoverMapCompareSavedAI LearningAI WeeklyAbout
← Library home
Guide 02 · Applied

How the Skill actually runs

The Skill is not a fancy prompt template. It is a worker that loads data, writes code in a sandbox, computes, and emits a self-contained HTML dashboard with JavaScript baked in.

3 things to walk away with
Real code
The agent writes and runs actual code in a sandbox — not LLM math.
Scales to libraries
Sandboxed execution handles large lists and libraries without context-window blowup.
Standalone artifact
The output is a self-contained HTML file you can open in any browser.

Code in a Sandbox — the agent writes real code, not LLM math

When the hiring Skill runs, the agent does not "think through" the candidate counts in its head. It writes a short program — the demo author describes it as "writing code to process the math or handle the complexity of the data" — and executes it in a sandbox. The numbers in the dashboard come from real computed output, not from the model's arithmetic guess.

SharePoint AI's worker-agent shape is the key differentiator. It writes code, runs code, and uses the results — that is how the dashboard's numbers are trustworthy.
The agent uses its language-model brain to count and sum candidates. It writes code that does the counting — completely different reliability profile, and how you get accurate large-dataset reports.

Beating Context-Window Limits

The author calls out the practical win directly: "you don't run into context window limits when you're generating code." A SharePoint list with thousands of rows would normally choke a chat model — too many tokens to load into the prompt. But if the agent only writes code that reads the list, the model never has to hold every row in memory.

The data lives in SharePoint; the agent writes a short program; the program reads what it needs. The model's context window only holds the code and the summary results, never the raw dataset.

Sandboxed code execution is how worker-agents handle real-scale SharePoint data. Context-window limits stop being a constraint because the model never sees the raw rows.
Big SharePoint lists can't be analyzed by AI because of context limits. They can — as long as the agent processes them with code instead of stuffing them into the prompt.

Live HTML Output — a real artifact, not a chat reply

The Skill's output is an HTML file dropped into a SharePoint folder. Complete with JavaScript for interactivity. The user can open it in the browser like any other file — click through the role breakdown, hover over the Sankey diagram, drill into at-risk candidates.

Because the dashboard is a generated file, it is durable. It does not disappear when the chat closes. It is shareable, archivable, and re-openable. Next quarter's run produces a new file alongside the old ones, and you can compare them directly.

A Skill that produces a file produces an artifact you can share, archive, and compare. That is different from a chat reply that disappears with the conversation.
The dashboard lives inside the agent chat and you have to re-ask the agent every time. The dashboard is a standalone HTML file in SharePoint — open it anytime, no chat session required.
Flashcards — Applied
02 · Applied
Code-in-Sandbox Execution
tap to reveal →
The worker-agent's signature move: write actual code, run it in a sandbox, use the computed results. Numbers in the dashboard come from real execution, not LLM arithmetic — which is what makes them trustworthy.
← tap to flip back
02 · Applied
Beating Context-Window Limits
tap to reveal →
By processing large lists with sandboxed code instead of stuffing rows into the prompt, the agent handles SharePoint datasets of any size. The model only holds the code and the summary, never the raw data.
← tap to flip back
02 · Applied
Live HTML Dashboard
tap to reveal →
The Skill's output: a self-contained HTML file with embedded JavaScript dropped into SharePoint. Interactive, shareable, archivable, re-openable — a durable artifact, not a chat reply that vanishes.
← tap to flip back