Lesson 2 of 8 · 9 min
Preparing Agent-Ready Data
Dashboard-ready data and agent-ready data overlap, but they are not identical.
A dashboard is a plated meal. The designer has already chosen the ingredients, portions, and presentation before the user sees it. A data agent walks into the pantry after the question arrives and must decide which source, fields, filters, relationships, and query pattern belong in the answer.
That means the data must carry more of its own context.
The five layers of agent readiness
Use five layers to assess every source you plan to connect.
1. Meaning
The agent needs business definitions, not only column types.
Ask:
- Are entity and field names understandable?
- Are important measures defined once?
- Are synonyms documented?
- Are similarly named fields clearly distinguished?
- Is the grain of each table explicit?
For example, a table called EnrollmentSnapshot should state whether each row represents a student, a student-term combination, or a daily student snapshot. Without grain, even valid SQL can double-count.
2. Metadata
Metadata tells the system what it is looking at and whether it should trust it.
Useful metadata includes:
- Descriptions
- Owners
- Refresh cadence
- Certification or endorsement
- Lineage
- Data-quality status
- Sensitivity classification
Descriptions should explain business use, not repeat the field name. “Student risk score” is weak. “Predicted probability from 0 to 1 that the student will not reenroll next term” is useful.
3. Access
The agent must respect the requesting user’s effective permissions on the connected source. That sounds simple, but the exact behavior depends on the source and the user’s role.
Check:
- Workspace and item permissions
- Row-level security
- Column-level or object-level restrictions
- Sensitivity labels
- Restricted attributes such as health, finance, or identity data
For Power BI semantic models, the requesting user needs model Read permission. Build permission is not required for this experience. Semantic-model RLS and OLS still matter, but remember that RLS does not restrict workspace Admin, Member, or Contributor roles.
For SQL and OneLake sources, validate the applicable row, column, object, and item permissions. Elevated workspace roles can bypass some OneLake security restrictions, so do not use an administrator account as proof that an end-user boundary works.
Test with representative user roles, not only the owner account.
4. Observability
The data source needs signals that indicate when it should not be trusted.
At minimum, know:
- The last successful refresh
- Whether expected row counts arrived
- Whether key fields are unexpectedly null
- Whether upstream pipelines failed
- Whether definitions recently changed
An agent cannot independently compensate for a broken pipeline. Your architecture must make data health visible.
5. Accountability
Every important concept needs an owner.
When two departments disagree about the definition of an active student, the model cannot settle the organizational question. It can only apply the definition it has been given.
Record who owns:
- Business definitions
- Source tables
- Measures
- Security decisions
- Agent instructions
- Evaluation results
Reduce the surface area
More data does not automatically create a better agent. Giving the agent every table is like handing a new analyst the keys to every filing cabinet and saying, “The answer is in there somewhere.”
A focused schema often produces more reliable query generation than exposing every table and field. Select only the tables required for the reliability contract from lesson one.
For the Student Success Advisor, you might begin with:
- Student
- Enrollment
- CourseAttempt
- Attendance
- Advisor
- RiskAssessment
Do not add finance, housing, admissions, and every historical staging table simply because they are available.
Prepare for the query language
The preparation differs slightly by source.
SQL sources
Document table grain, join keys, date fields, status codes, and approved calculation patterns. Example SQL queries are especially useful for complex joins or business filters.
KQL sources
Explain event timestamps, identifiers, event types, and useful time windows. KQL questions are often sensitive to when the event occurred and how the window is defined.
Power BI semantic models
Use the model’s Prep for AI capabilities: AI data schema, AI instructions, and Verified Answers. Keep measures and descriptions clear.
One important detail is that data-agent-level instructions are not passed into DAX generation. They can still help with routing or response behavior, but DAX-specific context belongs in the semantic model’s Prep for AI configuration.
Build the readiness scorecard
Score each category from 0 to 2:
- 0: missing or unsafe
- 1: partially defined
- 2: ready for the first evaluation
| Category | Score | Evidence | Owner | Required improvement |
|---|---|---|---|---|
| Meaning | ||||
| Metadata | ||||
| Access | ||||
| Observability | ||||
| Accountability |
A perfect score is not required. Clear gaps and owners are.
Exercise: create the question-to-source map
For each of your ten required questions, record:
- The expected answer
- The trusted source
- The tables or measures involved
- The required filters
- The permitted user roles
- Any ambiguity that must be resolved
Do not leave the expected answer as “whatever the dashboard shows.” Record the actual value, calculation method, or acceptable range for a known point in time.
This map becomes the bridge between business requirements and agent configuration. When the agent fails later, it will help you determine whether the problem is the data, the meaning, the query, or the expectation.
Carry this forward
Agent readiness is not a one-time cleanup project. Definitions, data, and permissions change.
The goal is to create a bounded, governed source where the agent has enough context to choose correctly and enough constraints to avoid improvising.
In the next lesson, we will turn this prepared foundation into the semantic and query context the agent uses at runtime.