Automating Content Production with Agentic AI Webinar

Hi, good morning everyone. Uh my name is Harry and I'm with Blueestream content solutions and thank you very much for joining us today. Uh we're excited to have you here for an automating content

production with a Gent AI. Uh it's a part of Bluestream's webinar series exploring the future of structured content documentation and intelligent content operations. We're pleased to be

content operations. We're pleased to be joined today by Michael Ian Costa, a senior director of knowledge platforms and engineering at Ala in conversation with Rael Bailey of Content Seriously.

Together they'll share practical insights into how advanced AIdriven documentation workflows are being developed and applied. So before we begin, thank you very much for being

here. We do hope today that you leave

here. We do hope today that you leave with some useful ideas, practical considerations, and a clear sense of what Agentic AI can be possible for your content production. And so with that,

content production. And so with that, I'd like to introduce over uh both of our speakers today. So I'll just add in Michael and I'll add in Rael. And uh

yeah, I'll pass over to Rael from here.

Thank you very much.

Thank you so much. Oh, hi Michael. I'm

so glad to be talking with you. Um I'm

just going to set the scene before we jump into it because I I know we there's so many questions that I have for you and we have a lot to cover in this hour.

So uh tech do teams are always being streamlined. you know, that the first to

streamlined. you know, that the first to get cut when there are cuts. And so, uh, we're expected to do more with less. And

so, we're expected to work hard, smarter, and not harder. And, um, but we know we can't cut quality because tech

docs has to be trusted information. And

so, now we can use AI to automate without having a drop in quality if we do it carefully. and uh Avalara seems to have cracked the code so to speak in

balancing efficiency with accuracy. So

my first question to you is in the context of documentation production, what makes AI agentic?

Thank you. I appreciate you having me today and and welcome everybody. I hope

this is informative and useful. Before I

answer that question, I just want to make one sort of disclaimer. Uh I am a practitioner. I have nothing to sell

practitioner. I have nothing to sell anybody here. uh which is different from

anybody here. uh which is different from a lot of webinars, right? Uh we're going to have a discussion today, not to show off what we have, you know, hi, look

what we have, but to show and explain what's evolving um in the most advanced shops in documentation and what your

organizations can have. Uh the reason why is because we want you to become an agent of change. In fact, there's a really good webinar coming up on that

very subject that I saw. Uh what we want you to do as the outcome of this webinar is we want you to explain to your leadership what they could have and we

want you to lead the effort. Uh because

if you don't developers are going to lead it who don't understand this space and they're going to define it and they're going to define you. uh and this

is your opportunity to lead and transform your roles into something new that not just we're reducing technical writers. I I just want to just sort of

writers. I I just want to just sort of kick off that little framing if you will myself uh but the difference between AI

uh AI alone and agentic uh AI is is truly a pacle. I mean, it's it's it's when people understand what we're doing and what you can do yourselves, uh, I

think it's really going to be, uh, I know it's an old frame, but, uh, it's it's a paradigm change.

Uh, today writers and shops are being asked to use AI, right? It's like, what the hell does that mean, right? Excuse

the French. I'm from New Jersey. Um,

you know, so what they do is they start using large language models directly.

you start prompting them. Uh you get we had a whole window of people thinking we're going to all become prompt engineers. That's going to be a whole

engineers. That's going to be a whole new career path. Um and that's just, you know, it's just using manual shovels to

try to, you know, build the world trace, you know. Um it's it really is. But that

you know. Um it's it really is. But that

was the first generation, right? Uh and

then we started building workflows. Uh

the one of the first workflows we built was uh taking completed support cases from we use Salesforce. So we took the Salesforce completed use cases which had

a massive uh corpus of knowledge that was collected during the process of receiving and solving that use case and

automatically building uh KCS support articles. But it was not aic, right? But

articles. But it was not aic, right? But

it was tremendously useful because we were using AI. We were calling AI and we were having AI synthesize all that input. Uh and it was deflecting cases

input. Uh and it was deflecting cases like especially the high repetitive ones where hey how do I change my password?

Well gee we can we can fire we can serve up instantly you know the process for changing your password or resetting it or whatever. uh so we cut a huge number

or whatever. uh so we cut a huge number of use cases but that was not agentic.

What makes something agentic first of all is an orchestrated workflow you or independent agents that work in concert

with each other um that each have roles.

They each have skills. There's many

agents. It's not just an agent. An

agentic uh content supply chain has many agents that work across the entire workflow from the inception to delivery

of of the content. Uh each agent or an agent has has skills. Uh those skills are defined and managed by the people

that understand what those skills should be. And guess who has the best knowledge

be. And guess who has the best knowledge of what those skills are, right? It's

the professional documentation people, not the engineers. Right. Right.

Um and then you know agents have memory right whereas when you puts things in straight into a large language model there's no memory model there to understand you know what what has

already occurred in in a in a transaction. You think it does but it

transaction. You think it does but it really it really doesn't. Um and it has true orchestration. Um there are two

true orchestration. Um there are two ways to approach it. I I've seen both.

you know, one where you have autonomous agents that just listen and wait to do something and then sequential agents that we can show you. So, when we when we talk a little bit more, uh, I'd like

to actually show a real agentic workflow for creating new documentation uh from brand new products, entire user guides, uh, and, uh, also new feature

documentation. So, uh, let's move on.

documentation. So, uh, let's move on.

Have some time uh, to cover that. Um so

um tell me very briefly what was like the ultimate goal that you're aiming for and how close to did you get to your goal just like uh a high level and we

can get into the details uh after after that. Yeah, this was this was not driven

that. Yeah, this was this was not driven by like a desire to shed writers, right?

Uh the motivation was the software development life cycle especially um is becoming agentified. There's swarms of

becoming agentified. There's swarms of agents that are now scanning thousands of Jira tickets for fixes, changes,

updates, even new new features. And

these agents are interpreting the need the jur tickets. It's literally making the changes to the code and then offering to check that code into git

repositories. Uh you know with the

repositories. Uh you know with the developers having you know the ability to then review and and commit. So we're

moving toward a 10x SDLC process. I'm

not kidding you right. This is really happening. This is beyond code

happening. This is beyond code generators like you know like cursor and and Q. This is this is beyond that

and Q. This is this is beyond that generation. What happens is the volume

generation. What happens is the volume of documentation that's going to be required because of the acceleration of product will overwhelm even you know the

average shop even if you hire writers is not going to be able to keep up with the volume of documentation that is stemming from this acceleration. So we have to do

that. The other the other aspect of it

that. The other the other aspect of it was we're identifying the whole process not just the documentation but everything from the very beginning of the development of a product with the

PRFAQ for example and we're really it's moving toward a doc first waterfall kind of model shockingly uh you know instead of this agile you know sort of model

that's been around and the documentation needs to be there quickly. So when you know when when my leadership came to me and they said hey uh we want to uh speed

this up. We we need much more higher

this up. We we need much more higher speed and higher velocity um they were saying we want turn rate turnaround of

documentation in 24 hours you know ready to publish right because those processes those SDLC processes are now operating

on 30 and 60-day models. So, this is not about, hey, let's just, you know, save resources. This is about how do you

resources. This is about how do you actually keep up? And what's going to happen is we're going to have a K-shaped kind of model here where some shops have these agent workflows and can keep up

and the shops that don't may have to hire a whole lot more writers.

Wow.

um had not thought of that that aspect of it, but that's um that's going to be encouraging to all the the tech people who are on the line um are in our

audience right now. But um uh okay, I'm going to go into that later, but before we really kind of dive into the details of of how you were reaching

these goals, um yeah, I think there are a couple of concepts that we need to understand. And so one is like the

understand. And so one is like the difference between probabilistic and deterministic models and why we need to understand the difference before you kind of dive into this.

Yeah, that's great. Uh you know people were very excited when generative AI hit. I I started with AI back in 1991.

hit. I I started with AI back in 1991.

It was called expert systems. Uh and then Watson uh for many years. Um those

were deterministic systems. They you literally there were literally learning systems, machine learning in in the Watson era that were based on things

like ontologies and and and models that uh had provenence. You knew where the answers were coming from, right? Okay.

When generative AI, it it was probabilistic, right? Or and I think everybody understands that that that general generative AI is a probabilistic kind of model. is looking

for the closest elements uh and you know and and vectors uh and it does a very very good job at it. So, uh, everybody popped the champagne corks real fast

after we were developing articles for support to divert, you know, uh, support cases because it was okay that our chat bots, for example, it got it right 50,

60, 70, even 80% of the time. But now

that we're in the agentic world, right, and you have many agents that have to make correct decisions, you can't afford that 20% maybe it's wrong

because down almost cascading down the entire chain. So when you see the

entire chain. So when you see the studies from MIT for example that only you know 95% 95% of of of AI projects are failing uh and only 5% are

succeeding and I even wonder about those 5% sometimes because I wonder if they're just workflows and not really agentic you know sort of workflows um the reason

is that probabilistic gap right it's what I call and I've said this before many times in my papers is it's it's called the precision paradox once you

get beyond that 80% % that last 20% is the hardest part to deal with and the tolerance for that 20% being wrong sinks

the closer you get to that 85 90 95%. So

you need to It's not that the large language model is bad. It's great at what it does. It just can't do it alone.

You have to pre-process content to give it only what it needs and what it should have and not overload it with too much context uh that it should not deal with.

And then you need validations both on the front end and the back end that are going to make sure that what is coming in is actually high quality input, right? Not garbage in and what's coming

right? Not garbage in and what's coming out is valid and accurate and tested and that requires a lot as well.

Right. Right. Wow. Yeah. So, um can you walk us through kind of how you got from the starting point to wherever you are

now? Like what are the major phases um

now? Like what are the major phases um of of how you um prepared uh your repository and then what you did

with that repository once it was um in good enough shape and so on.

Yeah, it it's is a fascinating uh area where I I think I think content management systems now are are one of the most important elements uh because you really need control over the over

the operations of your content.

When you say content management systems, you're talking about like at the authoring end like authoring systems or are you talking at the delivery and delivery systems?

Uh I'm talking about their role in the entire uh agentic workflow, right?

because because they represent the source of truth and the semantic uh intelligence that we need. So with with just the just generating new content

alone um you know we need we need better input right. So think about how

input right. So think about how technical writers have evolved right I started as a technical writer in 1981.

At the time we were receiving thousandpage specifications for operating system you know releases.

um we still had to go interview every single developer who owned a module uh and and ask a million questions in order to be able to write accurate and quality, you know, world-class

documentation because that's the way it was. Then we went to uh to agile and

was. Then we went to uh to agile and suddenly we got nothing and and technical writers became sleuths, right?

We became investigative journalists and it was go figure it out on your on your own. Uh we just wrote the code. Uh and

own. Uh we just wrote the code. Uh and

if you want to read our code, that's good. uh they trained me as a dual

good. uh they trained me as a dual writer programmer so I could read assembly language and and sit down with them and point out their bugs uh which blew them away very often because

technical writers wouldn't they know right um but but still we're here's the interesting difference I think that I'm facing with these agentic workflows uh

my leadership said we're going to move the responsibility for providing the knowledge collateral left we're going to move it up the chain We're going to make the program managers, right, the product

managers and andmesmemes responsible for providing that core knowledge, right?

However good or bad it is, right? Uh as

the input before the agentic processes even start. So right there there was a

even start. So right there there was a leadership decision, right? That uh that we're no longer going to let them get away with not providing the knowledge

collateral. And so we're going to put

collateral. And so we're going to put them in charge of the agentic workflow and role the role of the we know that they don't write very well

like they you know because they're not professional writers they're professional coders and so um how how did you get that quality um of what they provided good enough to be able to

extract the next uh yeah so that's called criteria so it's governance kind Yeah. Okay.

Right. So, we know what that criteria is, right? As professional technical

is, right? As professional technical writers, right? If you if you go look

writers, right? If you if you go look at, I don't know, Adida or any other well doumented uh set of questions that you need to ask

to write a worldclass task document.

There's probably about uh I have at least 30 or 40 questions that you ask immediately. You want to know who's the

immediately. You want to know who's the audience? What's their skill level? uh

audience? What's their skill level? uh

you know uh you know what's the goal of the task, what's the outcome, what are the exceptions, there's a whole litany of questions that need to be answered.

So so a you can build agents to go look at the collateral and say does it provide that knowledge in what's

provided and and it's not just one kind of collateral. We found for example that

of collateral. We found for example that some of the best collateral if we hold the providers to the standard is

recording video Zoom videos of using the product for real in in real time and explaining and including all of that information. So we have an agent that

information. So we have an agent that will parse through the videos and actually extract the text and extract the screen captures and look at it. Now

if we feel that that the quality or the sufficiency of the input and that's not just the video you now we're talking about the original PRFAQ we're talking about uh the you know what we call we

use cell so vzero the the the code uh the UI prototypes we're talking about the Figma collateral uh we're talking about any other written documentation we're talking about the code too even

though we only get a small amount of of value out of the code uh very good for API doc but not a a whole lot more uh and video demos. So, we have agents,

separate agents that can parse through every one of those kinds of pieces of collateral, right? We can and that'll

collateral, right? We can and that'll expand over time to be much more. And

then what we end up with is a pretty darn good draft that's about 80% there, right? So, now we now we've now

there, right? So, now we now we've now we've taken that 80%. Now you can debate whether or not you want a professional technical writer to take that 80% and bring it to 100 in the middle of that

workflow because there's still human in the loop, right? Or do you want to give that job to the engineers and make them suffer their own, you know, their own bad input before maybe at the very end

and have the professional technical writers do QA at the end. The other, you know, the other part of that process is is I love Manny Silva's book, you know, docs as code. He's got a new one coming

out for AI. I'd love to plug it. I wrote

the preface for it. Uh we can even ultimately identify docs as co uh as as tests because we can take that and say, "Hey, let's build automatic generators

that will test the actual product against what the final documentation is." So these are agents that's we we

is." So these are agents that's we we still have yet to build some of these agents, but we're in the pro we have all the core agents to to create net new documentation. than one we're doing

documentation. than one we're doing right now, literally by the hour, I just saw I was blown away by the by what I saw was updating existing documentation,

going through thousands or hundreds of thousands of topics and determining where we need to make uh specific updates when a product changes. That's a

mind-boggling complex uh endeavor. Uh

but but I I'm watching it and I'm watching it work and I'm I'm stunned that we can even make that work at this point. Um, so yeah, there's um there

point. Um, so yeah, there's um there there's a whole lot here and I I would love people to see even a foundational uh demo of a real agentic workflow in

action. I think we have one and I I

action. I think we have one and I I would love to to use that time and show people. It's a two-minute demo.

people. It's a two-minute demo.

Sure. Yeah, let's let's do it.

Hello everyone. Today I'm going to show you how we're using AI to automatically generate product documentation for net new features, reducing manual effort, speeding delivery, and improving consistency using our Aberriter system.

It all starts with our Jira documentation request tickets, which will include new attachments for documentation generation such as PR FAQs, video demos, Figma designs, Ezero

prototypes, and code repositories.

We're going to start the workflow off in the awriter app with options to trigger the workflow from Jira or Slack currently being built. There are several options for how the documentation can be

generated based on the needs of the ticket.

The workflow has five different agents that it goes through. A payload

ingestion agent, a content generation agent, a content QA agent, classification agent, and a publication agent. Going into the detailed view, we

agent. Going into the detailed view, we can now watch as the orchestrator goes through each step of the workflow, activating each agent as it goes. It's

going to start first with the payload ingestion agent, which will go through the Jira ticket, grab all the attached inputs, and process them for the content generation agent to use. The content

generation agent will then create a table of contents, and generate the content for each topic.

Content generation is now complete.

creating drafts that are not a rough starting point but are ready for review and refinement organized for both human readability and downstream systems like search and AI. A PMR writer can now come

in and review the content ensuring technical accuracy and content quality.

Once the content has been approved, they mark it ready for publication which triggers the classification agent. The

classification agent will analyze the content and apply the appropriate tax on taxonomy tags which will improve search for customers as well as the accuracy of AI tools like Abby that ingest the content.

The publication agent then takes over converting the content of data XML it to Ixiaoft or CCMS and publishing it directly to our internal internal knowledge center for final review before

going out to our customers.

The workflow is now complete. We can see the content live in our internal knowledge center and already publish it live for customers.

During testing, this endto-end process took less than 15 minutes with some light editing of the content needed. So

instead of starting from a blank page, we're reviewing and refining based on feedback, dramatically reducing time to delivery. We're turning documentation

delivery. We're turning documentation into a real-time capability that scales with the business. Thank you so much for listening.

Yeah. And that that's just a simple workflow of only a handful of agents. I

think I've uh we've laid out something like 25 plus agents that we still need.

We have, you know, think about automatic trademarking. Think about automatic uh

trademarking. Think about automatic uh accessibility conformance to WCAG standards. I talked about the DOC's

standards. I talked about the DOC's tests, right? Um there's so much more

tests, right? Um there's so much more that we have yet to build out for both net new and net update uh workflows. But

what's fascinating here is and and I want to share this with my with my peer writers. If we just let the developers

writers. If we just let the developers do this without us, they're going to think it's really simple and they're going to cut corners and you're going to get very very basic, you know, just couple of steps for how to do something

and none of the context and other information that needs to be there. I

managed, you know, I I have both an engineering team, dedicated engineers, and this is what you all need to ask for is some dedicated engineers because you're not going to get this from the vendors, by the way. I nobody can put

together an end toend workflow at this point. Each component

point. Each component is a is a piece of it, right? So, you're

going to get some help within their individual components that you're going to get some agentic AI. You're inside of each one of those. But to put it all together as an end to end, my

engineering team daily works handinhand with the professional documentation experts. Okay, there were no longer two

experts. Okay, there were no longer two separate teams. We're literally in the same room or virtual room every single day because my engineers, they're really

good at building something, but they don't understand and have the depth of knowledge of what worldclass documentation and processes are. for

example, I think what you said, what you're saying there is so profound, Michael, because so for so long there have been

these silos and um you know, we've always said, "Hey, why doesn't anyone talk to the content people and um you know, they're trying to kind of um read

everyone's mind and and you know, doing the best they can, but they aren't mind readers, so they don't know. and the

content people aren't um good at explaining kind of how important some of these things are. And so you've had these like two parallel tracks and they don't always like the train can't run on

them because they're going in all different directions. And so this is

different directions. And so this is bringing it into this kind of like um cross profession or cross-discipline collaboration is what can make the magic

happen. And I think that's such an

happen. And I think that's such an important point. That's why I I'm I I I

important point. That's why I I'm I I I we used to be called I don't know information developers you know years back and then exper and then you know experienced people and you know then we

moved on to different titles. I like to think of all of the professional documentation people today in this world as um as knowledge experience engineers

because they are needing to pick up these new roles and these new skills.

For example, you know, when we're using taxonomies, ontologies and knowledge graphs, that's not an engineering responsibility. That's a knowledge

responsibility. That's a knowledge management responsibility that belongs in the hands of the technical documentation professionals. Okay, the

documentation professionals. Okay, the skills uh think when we talk about agent skills um you can embed certain skills that are

never changing in the program logic but there's a lot of those agent skills that are variable and different for different contexts. So we externalized all of

contexts. So we externalized all of those prompts and skills in a separate system what's called an MCP hub so that the technical documentation professionals have total control over

the templates and the skills of the agents. So you can see very quickly

agents. So you can see very quickly what's happening is the technical documentation professional roles move toward an operational governance

responsibility and a QA responsibility and a design responsibility for these agentic systems. So there's a whole new set of roles and careers opening up and

I I talk about them at length in my paper on my website uh thinkingd documentation.com uh in one of my latest papers about all these new roles that are just emerging

and and I they didn't come out of like a guess that's literally what's happening in my own environment that uh yeah we're still need certain amount of technical

writers to handle all the edge cases u and exceptions because we can't handle everything every single use case. So,

there's still a need for that. Uh, you

know, maybe someday and, you know, when I'm long gone and buried, you know, we'll figure out how to do some of those edge cases. But, um, but there's much

edge cases. But, um, but there's much more opportunity. And I and once the

more opportunity. And I and once the business once your seniors m senior leaders see that you understand what the business can have and what the value is to the business, they're going to treat

you as the expert, not the developers.

because the developers can't even articulate the value prop. And so when they say we want best-in-class documentation, you've got to be able to challenge them and say, "Well, what is

the threshold for best-in-class documentation?" If I go through all of

documentation?" If I go through all of those things that are necessary to be included in a good quality task document or you know minimalism, you know, minimalism and and and other, you know,

progressive disclosure and all of those things, uh developers wouldn't know the first thing about those kinds of things.

I tell people go back and read the old bibles like go buy a I give the literally give the engineers I say go get a copy of developing quality technical information that the IBM

editors wrote years and years ago. It's

timeless. It tells you exactly what quality content is and exactly how to measure it, right? And it's no different today than it was then. Uh and and we need we need to educate them that that

no, just because you watch TV commercials does not make you a TV commercial producer.

Exactly. Exactly.

Holiday in last night, you know. Uh so

that there in lies the danger because what's going to end up happening is they will create technical debt that is so huge that one it's late right

so recently I was at a conference for um conversation designers uh conversational AI conference and they um talk every

uh every speaker on day one mentioned content debt and it wasn't a coordinated thing and they they all had it baked into their their decks um that they had

prepared beforehand and they were all worried about that because no one's ever really invested in the content at the beginning. So now you have all of this

beginning. So now you have all of this um that you know they're trying to get the chat bots to work well right at the delivery end. And if you're a bank, if

delivery end. And if you're a bank, if you're a financial institution, if you're an insurance company, if you're um medical, if you're in life sciences,

you can't afford to have that like you said, 80% uh is good enough. Like it has to be really really good. So, how do you reduce the content debt? And now I've

heard um there's a a woman from the Netherlands called um her name is U Micah and she came from technical writing went into conversation design

and she said she's no longer designing conversations now she's more like a LLM ops analyst and that's kind of what she does and so

the same way uh technical writing which I think was an anomaly anyways because writing was only 15% of what you did and the other is, you know, research and sleuththing and and stakeholder

management and research and all that.

And so, uh, you know, moving, um, tech writers from, uh, that state to knowledge, uh, you called them knowledge

experience, um, engineers. And I think that is, you know, like you've hit the nail on the head with that one, is that's what they're doing is they're engineering these systems now. And we

just had a question about what can tech writers do to become technical enough to create these agentic AI workflows.

That's great. Uh so you don't need to learn how to code. That's not what we want technical documentation professionals to do, right? No, really

we don't. I mean we got really I have phenomenal engineers. I only have you

phenomenal engineers. I only have you know a handful but they're great and they can implement what you want what you can design. And so we want you to be

the designer. We want you to be the the

the designer. We want you to be the the governance of what is designed the actual creator you know what the process is and I think this is the this is the craziness I was just talking to one of

my my devel developers you know I'm a very much a mentoring kind of manager uh and I said I said what's the first thing you do I used to go to IBM technical writing school we actually had an entire

university right at one at one point back in the good old days right and when you go to technical writing class 101 what is the very first thing they They cover very first subject right

know your audience right okay and what's the next thing you know you cannot not communicate right you know I mean there there's these

fundamental things that we all forgot why because we have ingrained in our in our beings as as professional technical documentation people right um

well there's also this other thing that you know I call it the the um black velvet Elvis uh syndrome which is that

um I think it was Liberace who hanging a big picture of a black you know Elvis painted on black velvet and you know obviously very tacky and would hang it

next to a Monae and he would say you know they're both art and so you get that thing where you know the product manager looks at something you know some

AI slop that got generated went good enough you know check documentation. And

now it's coming back to bite us because it's always cut, cut, cut, cut, cut, and invest in the marketing department, ignore the technical documentation. And

now it's coming back to say, you know, you racked up so much techn um content debt, you now need to remediate it, and nobody knows how except technical writers.

So look at it from my perspective. I'm a

senior director, which means I report to I report to a senior vice president. Um,

not to impress you, but what I'm trying to say is I see the numbers, right? I'm

literally in those leadership meetings where we're talking about things like ARR, you know, this is like new customer acquisition, uh, customer loss of, you

know, retention numbers, right? We're

looking at customer satisfaction, right?

Or here we call it CPO, customer pissed-off score, right?

um and all these different numbers that are tracked at the very very top of the business by the you know by the leadership top leadership and the board.

Um if you've got 30 seconds in an elevator with a CEO, I love asking this question. What would you ask? And I

question. What would you ask? And I

already know or or what would you say uh to to the CEO? And I would say uh do you want your customer retention, new customer and satisfaction to go up or go

down? you know, and and I say, you know,

down? you know, and and I say, you know, what communicates to your customer every single day the most other than the actual product interface, and why would you then not invest more

in that? I mean, that's my 30 minute

in that? I mean, that's my 30 minute elevator pitch to a CEO.

30 seconds.

30 second elevator pitch to a CEO to make him start thinking, you know something, that might be one of the most important things that we should be investing in and and expanding on, not not reducing because what he cares about

or what she cares about are those numbers and unfortunately we don't make the connection between what we're doing and what's happening in the boardroom and in the top of the business. Well,

that was my next question was like how does this um uh automation factor translate into business benefits is like cost, time, trust. What about the benefit to end

trust. What about the benefit to end users? And you know, I think with

users? And you know, I think with content, it's always been, hey, we all learn to write in grammar school, so we're all writers and or we're all content people. And I always say, you

content people. And I always say, you know, I counter kind of like you did with the um uh advertising. Watching ads doesn't make

advertising. Watching ads doesn't make you an ad producer, but you know, I learned to ride a bicycle, but I will never be able to uh you know, compete in the tour to France, never mind win the tour to France. And when you think about

like that, winning the tour to France, it's like how what makes your company succeed is that you're better than your competitors. And so you've got to win

competitors. And so you've got to win that tour to France. And you're not going to do it by giving someone a broken down bicycle and saying like, "Here, go ride up the hill." You know,

that's absolutely true.

So, um, talk to me a little bit more about like the, um, not just the business benefit, but the operational benefit.

Uh, expand on that question a little more.

So like uh you know if maybe you're cutting your drafts from you know this many weeks to that many weeks uh you're making things easier for the people who actually do the work to do to do the

doing.

That's right. Yeah. So there's

tremendous amount of of of grunt work that we all do, right? Um you know that like I said sifting through input, right? Uh that that's like the biggest

right? Uh that that's like the biggest one, right? that that chews us up trying

one, right? that that chews us up trying to go get that knowledge capital that uh you know because the process of learning which is what we do right as professionals is you know we we

associate we assimilate and we communicate right that's that's our basic process so you know I love this upstream we're going to push the responsibilities and the accountability

upstream because no longer can they get away with it and guess what if they approve something to be published you know and it gets out there and it's bad guess who we come back to and blame and not going

to be the technical documentation professionals because our our process is is good and we can measure and show that we had you know terrible low scores, inadequate input, inadequate review or

whatever it happens to be. Um we reduced the generation of the first drafts uh from two weeks to 30 minutes or less.

Wow. That is a measure that knocks the socks off of senior leaders because then they're saying, "Wow, you know, we really can accelerate this the speed and, you know, and the velocity of what

we're doing." It's not enough just to

we're doing." It's not enough just to look at it like documentation. You got

to make yourself part of the bigger process. When I talk about

process. When I talk about documentation, I don't just think about documentation. I think about the entire

documentation. I think about the entire SDLC, this entire software development life cycle workflow which includes everything from right this is now know

write the press release first all the way through delivery and support uh and enablement for for partners and and developers. So if you think about where

developers. So if you think about where you are in that bigger supply chain and your role, you can now start to explain

to your leadership why you need to accelerate and be accurate and be and have that provenence to prove yes uh

this has been you know this is world class this is best-in-class content. uh

that's going to take a lot of work, a lot of development to do and the people that know what that quality is and what the criterias are that need to be baked into all of this. And it's not static.

Once you build it, it's not something that oh, it's built and it's done. No,

these people who are moving from your traditional technical writer role into this knowledge engineering, you know, designer role or taxonomy management or knowledge graph management. So you need

people need to read and start studying through GPT right through large language models some of these areas I just published a paper I think it was yesterday morning first my first one in

a while I think it's like 10 pages long but it talks about what is a deterministic agentic system and how do you get there and it talks about things

like uh you know IDS an upcoming standard uh ontologies knowledge graphs context graphs If you're not asking GPT what these

things are and what they mean to documentation, you're doing yourself a disservice because you're not becoming fluent in the understanding. It's not

that you need to build them yourself, but you need to understand conceptually what they are so that you can say, "Hey, I need you to build me a knowledge graph

of our content and and oh, by the way, oh yeah, you need to understand, you know, what our constraints are and what the relationships are between things."

Great. uh you know their your role as as a documentation professional is to be the brains uh and let the engineers build

um and and you know and do it together as a team and that's where I see the the roles going uh not do I see technical writer jobs disappearing yeah pure ones

I do because I don't think that you can be a pure technical writer anymore and not contribute toward these next generation agent the whole notion of just using a large language age model

just feeding something to GPT manually or or a trained you know GPT model and prompting that that is going to disappear faster than you can imagine.

Um and and it's going to be were you part of designing and developing in concert with your development engineers and with your vendors. Uh

so I think of this and you know what I'm hearing you say is that um we're almost like

business analysts in the sense that we translate between user needs and what the engineers need to build. So between

business and technical. So we we have to be able to parse we have to be able to absorb what what is needed. We need to

be able to translate that into what the agents look like and then get someone to code it and then govern it.

And then govern it. Oh yes. everything

in case it's not clear to to uh some people in the audience it's like I'm hearing governance throughout this whole thing because who's going to hold feet

to the fire to say you have to provide like uh you know your engineers you have to provide this information to the people who are um you know parsing it

downstream you need to have that review cycle you need to have people committed to review you can't have the tech writer somebody said to me I literally chase people around the desk and like

corner them in their cubicles to get them to review something. Can't be doing that, right? Like you that they have to

that, right? Like you that they have to be responsible and so on and so forth.

So um and that's just part of you know the one thing where I disagree with you is I never use the word uh term supply chain because supply chain to me is like you create a book a physical book and

you sell it to someone and you never see that again. You never update that book.

that again. You never update that book.

you can make updates to it, but that's a new book that they buy and you never see it once it's sold. Whereas the life cycle, and you talked about this, like the complete development life cycle, the

life cycle takes into account that nothing's ever done, right? You have to decide whether it gets iterated or it gets sunset. And you do that over and

gets sunset. And you do that over and over again. Kind of like a slinky, you

over again. Kind of like a slinky, you know, it builds up around and around and around.

You're you're correct. Mine mine's

probably aging out at this point. my my

use of supply chain because really if you think about it if you did say uh DOC's tests correctly even agentically to automate it right

now you have a a a system of record of what is currently operationally the truth which can be input back into the

software development front-end process which nobody's even really thinking about in any really serious way. So if

we had validated accurate that's the current system of record right the other the other thing is people start need to thinking about is is identifying operations

operations become far more important in this world than they ever were we've always given operations a short shift right I mean gosh I used to go in front of a a gigantic audience at sidum or or

wherever at convex and say hey raise your hands how many of you actually have a uh an inventory a digital inventory of all of your content beyond a spreadsheet. And I'd get two hands

spreadsheet. And I'd get two hands raised in the audience. I was horrified.

You know, I said, let alone that was just their product documentation, not all of the userf facing documentation.

Now, we need to be thinking when you saw that demo, you saw a list of jobs, right? that was based on complete

right? that was based on complete inventory of every single publication that we have and all the metadata about every single publication that's been

automated and operations are going to be agentified too. So it's not just the

agentified too. So it's not just the production of content, it's also operations management gets into the game now in this in this agentic world. I

don't want to leave that out.

No, I can I can see that happening. Now,

we're coming up to um very quickly into Q&A. So, I'm I'm going to just ask um

Q&A. So, I'm I'm going to just ask um two question and I want them to be quick answers so that we can go to some of the questions that people have asked, but um how important is it to have semantically

structured content? Like we all come

structured content? Like we all come from a a data standards world. Uh we

have CCMS's uh you know this is sponsored by Bluestream that has a CCMS. How important is that? because we we're now hearing like oh there's markdown and there's HTML and markdown is dead and

HTML is the new markdown like so that's one question I have so quick answer quick answer is you want the most

semantically rich self-explaining content source that you could possibly need to a machine and telling it what it

formats like is not the same as what it is And exactly this is where all of those formats, this is where they said, "Oh, a couple years ago, right, six, seven, eight years ago,

did us getting along in the tooth." Now

it's the heart of what you need. And

it's not because the large language model consumes it. It's the

pre-processing with knowledge graphs where it's valuable. This whole notion of feeding structured content and markup to a large language model, forget about it. That's not where it's used. And

it. That's not where it's used. And

people have to disabuse themselves of that thought, right? You need to use it to build these intelligent deterministic knowledge graphs. And my new paper on my

knowledge graphs. And my new paper on my website goes deep into that.

Okay. And then uh if you know this is kind of like the the final question that I have before we take audience questions is what would be the top piece of advice you'd give to others who want to take on

a similar project in their organization?

Go to your leaders and say, "Look at what Amazon's doing over there with the automation of their documentation. Look

at what Manny Silva is doing. Look what

Michael's doing over here. We are

falling so far behind. We need the engineering resources and we need to be in control of directing them to build this and you will become the experts.

You'll save your jobs actually because your jobs will transform and the business will benefit from from doing it properly before they hit that in wall of

debt that they're going to inevitably hit because oh yeah, they watched a commercial, you know, and they think they could actually produce a Hollywood, you know, version tomorrow.

Yes, we can we can do music video.

Thank you. Let's take questions.

Okay. So, um we had uh one the first question that we had I think we kind of answered as we went which is you know how do we become technical enough to create these workflows. So a follow on

to that it was about the demo. The demo

seems to convey a very developerdriven process with tech writers as the human in the loops for simple copy editing. I

don't think this perception aligns with what you're advocating. So, how do you see the role of tech writers shifting and how can we convince our leadership that we need to engage with developers?

I think we've kind of answered a lot of that, but is there anything else that you want to say about that before I go on to some of the Yeah, I think yeah, I think the juryy's still out a little bit. Um, I've got my

popcorn ready. Um, as we're deploying

popcorn ready. Um, as we're deploying these agentic systems and making the the developers responsible for for being the the primary operators with the technical

professionals picking up the complex backend and exception cases and governance and all of that. Um,

developers are very highly paid people even more so usually than technical writers. They like to code and they

writers. They like to code and they don't like to produce clutter. Um

it's fascinating when you get a leadership that says no, they're going to do that. That's a that kind of support is incredible. Um it's where it belongs by the way because for too long

they got away without providing uh any knowledge collateral and you know so it's just and even when they do there's still going to be more information.

There's still going to be exceptions.

There's still going to be CA use cases that are not covered. This is where the technical doc professionals really come into the equation. uh because there's they're still going to be needed. I'm

I'm convinced of that. Um but with the volumes that are going to increase, there's no way they're going to be handle handle it without that kind of front end automation. So I think a combination now could be that certain

doc shops say no we'll we will require the input from from the you know from the knowledge knowledgeable creators of this thing from all those different sources I talked about but we're going to put the doc professionals in charge

of the postgeneration editing and and curation and QA. That's fine. Uh I

prefer I prefer a a collaboration kind of uh model of those two. But I I think I got my popcorn out because I think there's going to be quite a reaction frommemes

uh which been able to get away with a lot of this responsibility and accountability for a long time and I think it's going to be a fascinating uh result uh to see how is that going to

match up to the dictate coming from top down that says no you will do it that way.

So um another question that came in is isn't the basis of agents prompts prompt. Okay. So pro so uh an agent

prompt. Okay. So pro so uh an agent skills can be declared a couple of different ways right the two most prominent would be we can embed those

skills in the compile program logic. So

anything that's not going to be volatile can be can be put into into the program logic right right into your you know your your source code. But there's many

many skills that are prompts. But it's

not just prompts. You got templates uh that these uh that these agents use and other kinds of of of content that will go into the skills and the sub the the

infrastructure behind it. And it won't be isolated either. I mean, we've actually put our stuff uh in a whole MCP is called I don't want to go into MCP now, but a whole MCP model protocol uh

management structure. So, we should have

management structure. So, we should have the technical writers not only create and the the original prompts, but let's say you get a brand new document type uh that you've never had to deal with before. Well, you're going to have to

before. Well, you're going to have to develop the the agent skills to handle that particular document type because it's unique. It's different than all the

it's unique. It's different than all the other document types that you've dealt with in the past. And guess what? Those

are going to change over time. So we

built an entire management structure to manage us to allow the professional documentation people to directly own and manage all those skills and templates and things that have to be done in

addition to all the governance of the linting tools like you know acinks you know or or other similar uh kind of llinters that govern all of the editorial quality guidelines. I think

we're using uh we're we're using you know the successor today to that uh to acup which allows us to do lights out optimization too. So a combination of

optimization too. So a combination of both lights out and human optimization turns out to be a wonderful combination of the two. We can sort of get people 80% of the way there and let them handle

the last 20%.

Uh there was another question that uh was a follow on that was about um how internal a uh AI agent usage at

cloudfare grew 600% in three months and uh cloudfare just you know kind of wanted to reduce headcount. So um it

says will we need to upskill for example writing the AI agent skills and templates then govern all of it. I think

we've answered that. So, um, yeah. Okay.

Um, I'm gonna move on to who's better than the people watching this webinar. You are the skill. Here's

this webinar. You are the skill. Here's

the problem, right? We have, we may document the big rocks of our process, but professional technical documentation people know hundreds of things in their

brains that have never been written down. They do every single day just out

down. They do every single day just out of wrote of of their of their professional skills. And one of their

professional skills. And one of their skills has to be now be doing process analysis like you said and getting all of that knowledge out that needs to be

uh baked into all of this these agents that never really been talked about just it's because you learn it over time almost by osmosis right so there's there's hundreds of things

that we know as professional documentation people that that are not anywhere near in a Confluencer SharePoint repository and that makes

that institutional knowledge gold that needs to be managed and utilized.

So the uh we've got two more questions and they're kind of um um they intersect. So I'm going to kind of read

intersect. So I'm going to kind of read both of them and I think we can answer it in one. So um the first question is um with the increasing volume of

features from upstream engineering and shrinking documentation teams what content model balances agility structure and quality and what authoring and management approach is best suited for

both human and agent consumption doc's code data XML or an alternative and we did touch on that and then so someone else asked clarification please doc's

code so markdown versus data You said did it emphatically particularly because of pre-processing and knowledge graphs.

Can you elaborate asking because doc's code markdown static site generators doaurus mintify mntilify etc seems to be

all the rage and I've been watching this with my popcorn um over the next while and you know one of the things that uh struck me and this is kind of a bit off

topic but not really is that like schema.org or has just kind of deprecated the FAQ schema because it's

been gamified and so now it's it's um uh what do they call that um microact you know and so that will end up getting gamified so you know when we're looking

at you know how do we make our content robust what is the good content model and how do we balance that so that's we've got like two minutes to answer that before the top of the hour

yeah I'll just tell you a one minute story. So, uh, I worked closely with

story. So, uh, I worked closely with several people in the documentation space who were doing the most advanced work with knowledge graphs and they were manually trying to construct them and I said, "You're going to have heart heart

failure. You're talking about millions

failure. You're talking about millions of nodes that need to be not only created but maintained." And then we created what was called the document object uh model uh graphite project

which you can look up and it's also on my website where we realized anything with a schema especially a documentation format with a schema like data right or

an XML schema right if it's just an XML environment uh can automatically be used to used to automatically construct a

knowledge graph uh because that schema can become what's called the structural ontology and then all you need to do is is transform your content into a format

that the Ditto Ditto open toolkit does this already into a format that the graph can ingest. And so we're able to build an entire knowledge graph of the entire knowledge corpus automatically

and maintain it automatically that would take you incredible numbers of people to build and maintain. Now why a graph?

Because a graph is deterministic. It's

not probabilistic. it when when you shred your content up into vector databases and vector rag models, it loses the relationship of one topic to

another, it loses the links, it loses the metadata, it loses the declarative semantics that this is a danger versus a caution statement, right? It throws

everything away. But then when we query a graph to go find or mod that was content that we either need to deliver to a customer or modify and update, we

can pick out exactly the piece of content and only that piece of content that should be delivered to the large language model to the LLM, which guess

what costs exponentially less because we're not burning LLM tokens. And so we're not

only more accurate that way, we're cheaper by miles. And and and the LLM makers don't want you to know that, by the way, because they want you to burn

tokens, right? They think reasoning is

tokens, right? They think reasoning is is taking one one query, getting an answer, and then trying to run another probabilistic query on that one. What

they're doing is they're making you burn tokens. There there's also the uh

tokens. There there's also the uh gamification of this where uh I understand that at some companies um you know you're seen as more productive the more tokens you burn so they find ways

to burn tokens so that they they get rewarded for it. So this comes down to governance again, right? Like if

you incentivize the use of tokens, you're going to get the use of tokens, right? Yeah. So,

right? Yeah. So,

more more content, more context, bigger prompts create worse results.

Well, we're at the top of the hour, so I um I could talk to you for ages. And um

you know, Harry Oh, Harry's back. We

have to be careful what we say. No. uh

uh we are going to do something through kinetic um information you know the kinetic council uh where we do kind of like a an extended uh chat where we can

you know ask me anything and we'll just talk about this and then we'll um uh we'll publish it probably on YouTube but um uh in the meantime you know we have to stop because it is at the top of the

hour so I want to thank you so much uh I wish every uh client potential client would watch this before they embark on these these projects. So, u I found it

very interesting and very helpful. So, I

hope our audience did as well. And

Harry, I'm going to turn it back over to you to end wrap up the webinar.

Thank you.

You're on mute, Harry.

Helps to definitely be allowed. Sorry

about that, guys. Um, no, fantastic.

Thank you very much again, Michael, your time and Rael, your time. Fantastic. Um,

and again to the audience who are watching, thank you very much for all your questions. Apologies they weren't

your questions. Apologies they weren't able to be followed up in entirety, but we obviously will have a follow-up with Kinetic Council. Possibly we could keep

Kinetic Council. Possibly we could keep these questions as a uh a placeholder to address later on. But yeah, thank you very much. And uh this will obviously be

very much. And uh this will obviously be recorded, so we'll also republish this uh later on on our YouTube channel and on LinkedIn. Um so you will see the

on LinkedIn. Um so you will see the whole thing in its entirety. Um I found it extremely valuable. I'm trying to pick up my jaw off the floor a little bit here. But yeah, thank you very much

bit here. But yeah, thank you very much both and thank you everyone for joining us and uh we hope that you have a terrific afternoon and again all the best. Thank you.

best. Thank you.

Thank you.

Cheers.

Thank you. Thank you.