AI is the future of dashboards. The question is whose model, and where it runs.

Where the puck is: closed-weight tools that generate dashboards

A business user can describe the analysis they want, review a generated dashboard and refine it in conversation. Anthropic's dashboard tooling can write queries against connected data and show the query behind each chart, which gives the user a starting point and a way to examine what is being counted.

We see real value in that. AI helps with querying, modeling, interface development, testing and optimization. Its contribution extends well beyond choosing a chart, and experienced teams use it to deliver better software faster.

These tools are an example of a broader direction: dashboards and applications created with closed-weight AI models, where the provider does not release the model's weights. That describes the model. It says nothing about the application's permissions or ownership, which depend on how the application is built and deployed.

Producing working code does not settle the business decisions the code represents. Someone still has to decide what revenue means, how a return affects it, which period owns an adjustment and whether the result agrees with the accounting system.

I think there is a tendency right now to confuse generating a dashboard with building business intelligence. They are not the same thing. A mature BI application has to be correct, interactive, permissioned, organized across the enterprise and capable of evolving with the business. AI can accelerate that process tremendously. It does not eliminate it.

Alexander WrightPresident & CEO

At scale, the model behind the dashboard starts to matter. A closed-weight service is metered: every question, refresh and user is usage the provider counts, and the data the dashboard reads is sent to the provider's service to be answered. For a focused question that is a fair trade. For a company asking thousands of questions a day across finance, sales and operations it becomes overkill, in the way we have said Snowflake is for most mid-market companies: a great product, built for a scale most businesses do not have, with a consumption price that compounds exactly when the tool succeeds.

AI can reduce the time and cost of a BI program, and we should be clear about that. How much depends on the quality of the existing data, the complexity of the application and the responsibilities the team has to carry. A prototype built against one clean dataset and an operating environment serving several departments are different assignments. The second has to account for permissions, exception handling, deployment, testing, support and changes to the source systems, and those requirements remain when the code takes less time to write.

Our perspective on the real cost of business intelligence makes the related point that implementation and ongoing labor belong in the budget beside the software. AI changes how that labor gets done. A responsible comparison still includes it. Read the real cost of business intelligence

Where it is headed: your own model, inside your own environment

The models that matter for this work are getting smaller, better and more open. Open-weight models, whose weights the provider publishes, can run on infrastructure the enterprise controls, be tuned to its vocabulary, its definitions and its data, and answer through the permissioned APIs the application already has. The model becomes one more governed layer of the environment rather than a service the environment calls out to.

That changes three things. Information stays inside the environment the business already controls, under the same permissions as every screen and export. Usage is limited by the capacity the business chooses to run, not by a meter on every question. And the long-term price is the fairest one available: the cost of the capacity, the application and the team, rather than a charge that grows with every person who finds the dashboards useful.

Closed-weight tools remain the fastest way to start, and we use them. The destination is a dashboarding environment where the intelligence is as owned as the data.

That is the direction we are taking Co-Wright Intelligence: toward open-weight models inside the Co-Wright environment, customized to each partner's business and answering through the same permissioned APIs, so our partners stay safe and in control of their information at a price that stays fair as their use grows.

What makes the application useful

Whichever model serves the dashboard, closed-weight today or open-weight inside your own environment, the application around it has to meet the same requirements. A mature BI application has to work the way the business works. The visible dashboard is part of that experience, and getting the experience right is substantial work in its own right.

The numbers have to be correct

Sales may call an opportunity revenue. Finance may recognize revenue only after an invoice, a delivery or another accounting event. Operations may need a different view again. Each can be legitimate, provided the definitions are explicit and the relationship between them is understood.

The application needs agreed definitions, a clear source for each measure and checks that find missing, duplicated or conflicting records. Users should be able to see the period, scope and freshness of the number they are reading, and when a total changes, someone should be able to explain why. Read how we approach connecting systems

Interaction has to support a decision

A useful view lets someone move from an exception to the records behind it. Filters work together, drilldowns preserve context, and saved views, exports and comparisons behave predictably, so nobody has to rebuild their analysis every time they open the application.

Where the process calls for it, analysis connects to an action: adding commentary, reviewing a commission adjustment, updating a forecast, approving a transfer. Each action needs the right permissions, validation and history. Adding a button is only the beginning of making that workflow dependable. Explore Business Intelligence on Co-Wright

The enterprise needs a coherent experience

The CFO, a regional manager and a salesperson need different views of the business. They should still be able to reconcile those views to shared definitions and understand how one relates to another.

That takes deliberate organization: navigation by responsibility, consistent terminology, common filters and a clear route from company performance to department, customer and transaction detail. A collection of individually impressive dashboards can still be difficult to use as an enterprise application. The goal is for each person to find the right information in the context of their job, without creating a separate interpretation of the company.

Permissions have to hold when the data is mixed

A company may keep everyone's sales in one table and everyone's compensation in another. That is a normal data structure. The application still needs to know who is signed in, what they are allowed to see and which actions they can take.

Giving the AI a written instruction about those boundaries does not establish them. Access has to be enforced by the system that supplies the data, independently of what the user asks or what the model generates.

Salesperson A can see their own customers, sales and commissions, and Salesperson B has the same access to theirs. Both sets of records sit in the same source, and A asks the AI to compare the two commissions. The system should derive A's identity from the authenticated session and apply the access rules before any data reaches the AI or the browser. It should not retrieve B's records and rely on the model to leave them out, and the same rules have to hold for drilldowns, exports and direct API requests. A sales director may be authorized to see both representatives, and that access should come from an explicit permission, not a more persuasive prompt. Team benchmarks need their own rules too: a total that lets A work out B's number by subtraction still reveals it.

An authorized HR user may need individual salaries and compensation history to do their job. A department manager may need headcount and an approved payroll total, and a salesperson should receive neither another employee's salary nor that employee's history. That requires permissions for records and for fields, so the same request can be allowed for HR and denied, or answered with an approved aggregate, for everyone else. Shared dashboards, saved results and caches have to preserve the boundary: a view created by HR should not pass HR's access to everyone who opens it. The test is what each user can actually retrieve.

Co-Wright declares row and column filters on the underlying model and enforces them through its API. Dashboards, lists and forms inherit those rules. See Security and Permissioning

What makes the application dependable

Performance has to survive real use

A dashboard that works for one person on a small dataset has passed one test. Production adds years of history, simultaneous users, large exports and more complicated combinations of filters. The database, the queries, the API and the interface all affect the result, so the application has to be tested under the load it will actually carry, optimized, and watched for deterioration as the data grows. AI can help with that work. The standard remains whether the application is responsive and dependable for its users.

The environment has to keep evolving

A supplier changes a file format. An ERP is replaced. The sales organization adds a region. A compensation rule changes halfway through the year. The system has to absorb those changes while preserving the history and the controls the business relies on. That takes monitoring, visible failures, an audit trail, tested releases and a team that knows what the application is supposed to do. A generated dashboard can become a production application, but someone has to take responsibility for that transition and for everything that follows.

Co-Wright's warehouse validates and audits incoming data, reconciles it against the source systems nightly by default and is built to surface pipeline failures rather than hide them. Those controls support the application the user opens every day. Explore the Co-Wright data warehouse

Who can find and fix the actual problem

A revenue dashboard shows a lower number on Monday morning. The chart still loads. Is the source missing invoices? Did a connection expire? Did a query count the wrong date? Is the API returning incomplete results, or is the browser showing an older version?

Asking AI to rebuild the chart may change what you see without identifying what went wrong. The person responsible has to trace the result from the source through the transformation, the query, the API and the deployed interface, which takes access to the logs, the code and its history, and an understanding of the business rule being represented.

The fix is then tested against the source, checked for its effect on permissions and other views, and released through a controlled process, with a known way back to the previous working version if it fails. AI can help investigate and repair the system. Someone still has to understand the diagnosis, have the authority to make the change and verify that the fix is correct, and that responsibility should be clear before the business depends on the application.

Where the application lives matters

Once people rely on a dashboard, it matters where its front end is stored, where it runs and who can change it. A shared link gives you access to an experience. It does not, by itself, tell you how that experience is operated or what you can take with you.

Is the source code in a repository your business can reach, in a developer's account, or only inside the tool that created it? Who controls the hosting account and the production deployment? Which version is live, and who can restore it if the person who built it leaves? Downloading the front end can be useful, but it may still depend on a database, APIs, authentication, credentials and services that are not in the download. The practical question is whether another qualified team could rebuild and operate the full application from the code, configuration and documentation available to it.

Data ownership, rights to custom application code, the license to an underlying platform and control of hosting are separate questions, and the answers depend on the agreement and the deployment. Using AI to create an application does not resolve them. You should know what can be exported, what remains dependent on a provider, and what continuing to run the application would require if an account is closed or a technology partner changes.

A mature application has a location, a release process and people with the access and knowledge to maintain it. Those are part of what you are evaluating when you decide whether a dashboard is ready to become enterprise software.

More dashboards make shared definitions more important

When creating a dashboard becomes easier, a company creates more of them. That expands what people can investigate. It can also multiply inconsistent definitions if each dashboard is built on its own.

One team excludes returns. Another includes them. One filters by invoice date, another by order date. Both reports say sales, and both may look convincing.

This is a risk of unmanaged reporting whether the dashboard was generated by AI or built by hand. AI increases the speed at which the problem can spread. It also gives a well organized team a faster way to extend a governed environment.

The opportunity is to give people freedom to explore against agreed business definitions, with a clear path for reviewing useful analysis and promoting it into the shared application. That is how self-service becomes a capability the enterprise can rely on.

The application spans the whole delivery model

We build with AI, through Co-Wright, with the SEAD team accountable for implementation and ongoing operation. Three contributions work together across the application.

SEAD's work includes the experience people use as well as the foundation behind it. We design the views, shape the interactions and connect information to workflows, then maintain that environment as the business asks more of it.

The salesperson and HR scenarios test the permissioning and API layers. The Monday-morning revenue example tests whether every layer can be investigated. The ownership questions test who controls the code, the deployment and the continuity of the application.

An AI interface can also be another way to work with governed business data. Our view on AI describes Co-Wright's APIs and MCP infrastructure as part of that direction. The right design depends on the customer's requirements and has to be validated in the actual environment. See how CIOaaS works

What this looks like in production

The client stories make the distinction concrete. Each began with a business process that needed to work better. The dashboards became part of the system that improved it.

MedTech MedCare

At MTMC, more than 100 commission data sources are normalized into one model. Representatives see what they earned and why, a reviewer checks every sheet before anything sends, reruns are selective, and disputes are handled in the system with a full audit trail. The reporting cycle moved from six months to ten days, and more than 200 permissioned users work in the environment.

View full screen

Read the MedTech MedCare story

Direct Supplies Warehouse

When DSW moved from Epicor to NetSuite, Co-Wright kept the order history and the reporting running through the cutover. Between NetSuite and DispatchTrack it adds the checks the native connector lacked: an audit log of every sync and daily alerts when something does not reconcile. More than 90 permissioned users work across the office and the warehouse floor, on fill rate with its per-order drill-down, supplier lead time, open orders and sales order packing. The value is a connected operating experience that kept working while the ERP changed.

View full screen

Read the Direct Supplies Warehouse story

CFGI

CFGI's recruiting began with an Excel process and a few dashboards. It grew into one portal across LinkedIn, Lever and Retain, and AI ranking, application review, right-role recommendations and screening questions were added as the technology matured. More than 60,000 resumes have been processed, at a 70% lower cost per hire than a traditional recruiting firm. It is a practical example of AI extending an existing system.

View full screen

Read the CFGI story

Use the tool that fits the job

If you have a clean dataset, a focused question and someone who can validate the result, an AI-generated dashboard may be exactly what you need. That is a sensible use of the technology.

As the requirement grows, evaluate the whole application: how the data is defined, how users interact with it, who can access it and who will keep it working. A capable internal team can build that environment with AI. An embedded partner can build and operate it with you. The responsibilities remain in either model.

Questions worth asking before you scale

Build intelligence the business can rely on

We believe AI should make businesses more capable and technology teams more productive. The goal is to use that speed to create software people can trust and use across the enterprise.

That is how we think about Human Intelligence × Artificial Intelligence. The business knowledge, engineering judgment and accountability around the technology determine what it becomes, and the direction is toward intelligence a business runs for itself.

If you have built a dashboard with AI, bring it to us. We will look at what is already working, what your users need next and what it would take to make it dependable across your business.