Who it is for
- Leadership teams with several AI ideas but no defensible priority
- Operators who can see friction but do not yet know whether AI belongs in the answer
- Organizations preparing an AI roadmap, pilot, or investment decision
AI assessments for decisions that need to hold up.
Understand where AI belongs, what needs to be fixed first, and what should not be built.
- Paths
- Four focused assessment types
- Typical range
- 1 to 3 weeks when scope and access are ready
- Output
- A practical decision packet
Choose the decision in front of you.
Each path examines a different part of the problem. All four lead to a clear recommendation grounded in the business, available evidence, and technical reality.
AI Opportunity and Readiness Assessment
Decide where AI could help, what deserves attention first, and whether a simpler intervention would be stronger.
Review this assessmentAI Product and System Assessment
Review an idea, prototype, AI feature, or live system before committing to the next build or release.
Review this assessmentAgent-Ready Software Assessment
Prepare internal or customer-facing software for agent discovery, traversal, and controlled action.
Review this assessmentData and Analytics Readiness Assessment
Determine what is preventing dependable reporting, forecasting, analytics, or AI work.
Review this assessmentAI Opportunity and Readiness Assessment
Decide where AI could help, what deserves attention first, and whether a simpler intervention would be stronger.
Questions it answers
- Which workflows contain enough value and repeatability to deserve attention?
- Where can AI help, and where would ordinary software, automation, or process repair be better?
- What data, access, ownership, and operating constraints affect feasibility?
- What is the smallest credible next step, and what should wait?
Evidence examined
- Representative workflows, decisions, exceptions, and handoffs
- Existing applications, integrations, data sources, and ownership
- Candidate opportunities and the assumptions behind them
- Security, privacy, adoption, and change constraints
- Non-AI alternatives and the cost of leaving the current process alone
What we need
- Access to people who understand the workflow in practice
- Representative documents, reports, or system examples where available
- A sponsor who can clarify priorities and make tradeoffs
What you receive
- Current-state workflow and system map
- Prioritized opportunity set with AI and non-AI options
- Feasibility, readiness, risk, and dependency findings
- Recommended next step with explicit no-go boundaries
- Implementation outline and next decisions where appropriate
When another path may be better
If the opportunity is already defined and the question is how to build it safely, a product or system assessment may be the more direct route.
AI Product and System Assessment
Review an idea, prototype, AI feature, or live system before committing to the next build or release.
Who it is for
- Product teams deciding whether an AI idea is ready to build
- Organizations with a prototype that needs an independent production review
- Owners of live AI systems facing reliability, cost, security, or maintenance questions
Questions it answers
- Does the product solve a clear user problem, and is AI necessary to solve it?
- Can the architecture support the required behavior, controls, and operating load?
- How should model quality, cost, latency, and failure be evaluated?
- What must change before a prototype can become dependable software?
Evidence examined
- User need, product boundary, and representative tasks
- Architecture, model behavior, prompts, context, and tool use
- Data paths, permissions, security, and privacy controls
- Evaluation coverage, failure handling, cost, and reliability
- Deployment, observability, maintenance, and ownership
What we need
- A clear idea, prototype, feature, or live system to examine
- Access to relevant code, architecture, test cases, or product owners
- Representative examples of success, failure, and edge conditions
What you receive
- Product and architecture findings tied to the intended user result
- Model, data, security, reliability, and operational risk review
- Evaluation and acceptance plan for the next release
- Recommended architecture and delivery sequence
- Build, simplify, defer, or stop recommendation
When another path may be better
If the product is still only a broad business question, begin with the opportunity and readiness assessment. If the main uncertainty is data, use the data and analytics path.
Agent-Ready Software Assessment
Prepare internal or customer-facing software for agent discovery, traversal, and controlled action.
Who it is for
- Owners of established software that agents need to understand or operate
- Teams exposing legacy or internal systems through safer modern interfaces
- Product leaders preparing customer-facing software for agent use
Questions it answers
- Can an agent discover what the software can do and interpret its concepts correctly?
- Which reads and actions can be exposed safely, and which must remain restricted?
- How should identity, permissions, approvals, recovery, and auditability work?
- What is the first viable agent workflow, and which interface changes does it require?
Evidence examined
- APIs, schemas, semantics, documentation, and interface consistency
- Identity, scopes, permissions, approvals, and action boundaries
- Tool design, compatibility, error handling, and recovery
- Observability, confirmation, audit records, and maintenance
- Candidate agent environments and one representative end-to-end workflow
What we need
- Access to the product or internal system and people who understand it
- Existing API or interface material where available, even if incomplete
- A proposed user or agent workflow with a meaningful business result
What you receive
- Agent-readiness findings across interfaces, semantics, identity, and control
- Capability and action-boundary map
- First viable workflow with security and confirmation requirements
- Interface architecture and staged modernization plan
- Testing, observability, ownership, and maintenance requirements
When another path may be better
If the software needs broader modernization before agent access is useful, we may recommend conventional application, API, data, or identity work first.
Data and Analytics Readiness Assessment
Determine what is preventing dependable reporting, forecasting, analytics, or AI work.
Who it is for
- Organizations whose reports disagree or require repeated manual repair
- Teams preparing forecasting, analytics, or AI work on uncertain data
- Leaders who need a dependable decision path before investing in platforms or models
Questions it answers
- Which decision must the data support, and what definitions make it trustworthy?
- Where do source, quality, lineage, access, and ownership problems enter the path?
- What should be corrected in process, governance, integration, or modeling?
- What is the first deliverable that can prove the approach?
Evidence examined
- Source systems, extracts, transformations, and delivery paths
- Measures, business definitions, reporting logic, and reconciliation
- Data quality, lineage, access, security, and retention
- Ownership, validation responsibilities, and change control
- The reports, forecasts, analyses, or AI use cases the data must support
What we need
- A decision, report, forecast, or use case to anchor the review
- Access to representative sources, outputs, and subject-matter owners
- Willingness to resolve disputed definitions and ownership questions
What you receive
- Current-state data and decision path
- Definition, source, quality, lineage, and ownership findings
- Prioritized remediation plan with immediate and structural work
- Target data path and validation approach
- Recommended first deliverable and next decisions
When another path may be better
If the data is dependable and the remaining question is product design or model behavior, a product and system assessment may be more useful.
Evidence first. Then the technical call.
Forward deployed engineering keeps the assessment close to the real workflow and the people responsible for it. The recommendation is not decided in advance.
Understand the business
Learn the workflow, people, systems, exceptions, and decision that prompted the review.
Inspect the evidence
Review representative systems, data, documents, code, and operating examples rather than relying on workshop impressions.
Test important assumptions
Check feasibility, behavior, constraints, and failure conditions with the smallest useful amount of technical work.
Compare interventions
Consider AI, ordinary software, automation, data work, process repair, waiting, and doing nothing.
Make the technical call
Recommend what should happen next, state the no-go boundaries, and identify what still must be decided.
A decision packet you can act on.
The assessment is useful even if Permadyn does not implement what comes next.
- Current-state workflow and system map
- Material constraints and unresolved questions
- Feasibility, risk, and readiness findings
- AI and non-AI options
- Recommended next step and explicit no-go boundaries
- Architecture or implementation outline where appropriate
- Ownership, sequencing, and next decisions
What this is not.
No generic workshop theater, vendor pitch, unsupported ROI estimate, artificial maturity score, or automatic AI recommendation. We may recommend a smaller intervention, more preparation, waiting, or no project.
What shapes the scope.
Breadth, participant count, access, system condition, source count, security needs, and specialist review determine the effort. Pricing is private and defined against the evidence required.
Questions about the assessment.
Clear access, boundaries, and ownership make the review more useful.
Which assessment should we choose?
Choose the path closest to the decision in front of you. If the problem crosses several paths or is still unclear, select Not sure. We will narrow the review before it begins.
Who should participate?
Usually an accountable sponsor, people who perform or own the relevant workflow, and technical owners for the systems or data involved. The exact group depends on the question.
Can the assessment be completed remotely?
Yes. Most evidence review, interviews, system walkthroughs, and decision sessions can be completed remotely. On-site work can be considered when physical operations or access constraints make it useful.
How do you handle sensitive information?
We agree on access and handling before the review. We ask for the minimum evidence needed and can work with sanitized examples, controlled access, or the client environment when appropriate.
Can you assess software built by another team?
Yes. The purpose is an independent view of the current product or system. We focus on the evidence, not who built it.
What affects the timeline?
Breadth, participant availability, access, system condition, source count, unresolved definitions, security needs, and specialist review all affect the schedule. The published ranges assume a focused scope and timely access.
What affects the investment?
The same factors that affect time also shape effort: breadth, participants, access, technical condition, data sources, security requirements, and any specialist depth needed. We define the scope before work begins.
What happens after the assessment?
You receive a decision packet that can stand on its own. Permadyn can help execute the recommendation, your team can own it, or you can decide not to proceed. Implementation is not assumed.
Request an assessment.
Tell us what needs to be decided and what exists today. We will confirm the right assessment path, access needs, and scope before work begins.