Project plans and baselines for Agile is like trying to fit a square peg in a round hole
--------------------------------------------------
The basic premise of agile is that you cannot make a project plan and baseline it - because requirements change and technology changes.

To make a project plan, you need to know all of the requirements in advance, create a work breakdown structure (WBS) that accounts for all of the tasks needed to be done to accomplish those frozen requirements. Agile says that you cannot know all of the requirements in advance, that they emerge during the project. This is the reason [Jeff Sutherland, co-founder of Scrum, says][1]:

> The venture capitalists I work with say they have never seen a
> correct GANTT chart in a board meeting.

Also see this [report from Forrester Research, "Common Project Management Metrics Doom IT Departments to Failure"][2]:

> The metrics organizations commonly use to determine whether an IT
> project is a success or a failure—whether the project is completed on
> time, on budget, and delivered the initial requirements—do more harm
> than good for IT departments.
> 
> "Project requirements change for a variety of reasons, and schedules
> and budgets change during the lifetime of the project based on better
> information as to effort, complexity and interdependencies."

So, to answer your second question first:

> How to obtain the classical artifacts (which are necessary to report
> back to the business) in an Agile environment which focuses on
> delivery?

Don't try to obtain classical artifacts in an Agile environment. They will show successful projects as failures and vice versa.

And to answer your first question:

> Do Agile projects have Charters, project plans and baselines?

Agile projects do not have project plans in the traditional sense and certainly not baselines. But Agile is not anarchy. As a business, you do need to know what the ROI is before making an investment decision. You can certainly have a Charter. But instead of project plans and baselines, you can have a [roadmap with specific business goals you are trying to accomplish in each sprint/release][3].


  [1]: https://www.scruminc.com/story-points-why-are-they-better-than/
  [2]: https://www.cio.com/article/2434560/project-management/common-project-management-metrics-doom-it-departments-to-failure.html
  [3]: https://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/